Hacker News: abelanger

New comment by abelanger in "The startup's Postgres survival guide"

abelanger — Wed, 22 Jul 2026 16:20:12 +0000

> I do wish the guide was expanded a bit with lots of specific examples and details... a lot of it is hand-wavy blurbs.

I appreciate the feedback; I'm usually someone who tends to go into way too much detail, so this was difficult to write - I tried to focus on the "mental model" of understanding Postgres rather than very nuanced specifics. I tried to link out to my favorite articles on a number of subjects, and the Postgres manual is quite good.

Some external links from the article:

- https://www.digitalocean.com/community/tutorials/database-no...

- https://www.cybertec-postgresql.com/en/benefits-of-a-descend...

- https://martinfowler.com/bliki/ParallelChange.html

- https://www.cybertec-postgresql.com/en/tuning-autovacuum-pos...

Some internal links on where I've gone into our own use-cases in more detail:

- https://hatchet.run/blog/multi-tenant-queues (PG-backed queues)

- https://hatchet.run/blog/postgres-partitioning (PG partitioning)

(edit: formatting)

New comment by abelanger in "The startup's Postgres survival guide"

abelanger — Wed, 22 Jul 2026 16:05:42 +0000

OP here, I appreciate this.

> in addition to minimizing locked records, make sure your locks are ordered deterministically across all queries (eg by id asc, always) or you’ll deadlock (but postgres has a really good deadlock detector so you’ll more likely just error out if you’re lucky)

This is really good advice, I should put this somewhere in the guide. To add to this, not only can you deadlock by not having a consistent `ORDER BY` when you're locking sets of rows, but you should also be careful of locking rows on tables in different orders. For example, even if you lock each row in a table with an ORDER BY and FOR UPDATE, if one tx locks `table_a` and then `table_b`, and the other locks `table_b` and then `table_a`, you'll deadlock. This is obvious in theory but exponentially harder to debug in practice, because you need to be globally aware of every table that a write touches - something that's bitten us in particular with certain extensions.

> learn about GIN (and GIST) indexes

We're just testing GIN for fast key-value lookups for JSONB columns, and the performance improvements have been really massive. Interestingly there was a large performance skew between AND vs OR on these key-value queries.

New comment by abelanger in "The startup's Postgres survival guide"

abelanger — Wed, 22 Jul 2026 16:00:32 +0000

OP here, I appreciate the feedback! I tried to focus on things which could take down your database, so things like particularly slow reads and writes, autovacuum settings, reducing lock contention, particularly focused on cases that I've seen. There are lots of things that I left out which would belong in a general user guide.

We're heavy users of stored functions because we're (perhaps overly) reliant on Postgres triggers, which can improve performance by reducing network round-trips but are fairly risky because they're difficult to monitor and observe.

The startup's Postgres survival guide

abelanger — Wed, 22 Jul 2026 12:36:08 +0000

Article URL: https://hatchet.run/blog/postgres-survival-guide

Comments URL: https://news.ycombinator.com/item?id=49005787

Points: 502

# Comments: 221

New comment by abelanger in "Ask HN: Who is hiring? (June 2026)"

abelanger — Mon, 01 Jun 2026 20:50:26 +0000

Hatchet | Full-Stack Engineer | NYC or SF or REMOTE (US and EU) | https://hatchet.run

Hey HN! I'm Alexander, one of the founders of Hatchet. Hatchet is an open-source platform for running background jobs at scale.

We're hiring engineers who are excited to build the next class of engineering primitives, starting with queues, background tasks and durable execution. We started in early 2024 after launching our distributed task queue (https://news.ycombinator.com/item?id=39643136).

Hatchet is currently used by thousands of engineers for all kinds of workloads: log ingestion pipelines, code review agents, video encoding, GPU scheduling, etc. Our target customer is fast-growing startups who have a strong need for background jobs system. These days, that tends to be AI companies, though we're general-purpose and not exclusively targeted for AI workloads.

Stack: Postgres, Go, Typescript, React, Kubernetes

Applying: email me at alexander@hatchet.run and tell me about something impressive you've built, along with your CV and why you're interested in Hatchet.

Note that we're fully open-source, which you can check out here: https://github.com/hatchet-dev/hatchet (and if you have thoughts / opinions / questions about the codebase, please include those in your note!)

Durable execution, the hard way

abelanger — Thu, 28 May 2026 12:11:03 +0000

Article URL: https://github.com/hatchet-dev/durable-execution-the-hard-way

Comments URL: https://news.ycombinator.com/item?id=48307802

Points: 64

# Comments: 3

New comment by abelanger in "GitHub's Fake Star Economy"

abelanger — Mon, 20 Apr 2026 16:01:22 +0000

> Our analysis revealed the fork-to-star ratio as the strongest simple heuristic for identifying potential manipulation. The logic is straightforward: a star costs nothing and conveys no commitment. A fork means someone downloaded the code to use or modify it.

This is just clearly...incorrect? You can both modify code without forking it and most software is distributed via a registry or binary download, which also wouldn't be represented in forks. For most projects, the number of forks is a lossy signal for how busy the contributor ecosystem is, nothing else.

New comment by abelanger in "Supertoast tables"

abelanger — Fri, 06 Mar 2026 19:17:21 +0000

Candidly we're still trying to figure that out: all of the plumbing is there in the open source, but the actual implementation of writes to S3 are only on the cloud version. This is partially because we're loath to introduce additional dependencies, and partially because this job requires a decent amount of CPU and memory and would have to run separate from the Hatchet engine, which adds complexity to self-hosted setups. That said, we're aware of multi-TB self-hosted instances, and this would be really useful for them - so it's important that we can get this into the open source.

The payloads are time-partitioned (in either case) so we do drop them after the user-defined retention period.

Supertoast tables

abelanger — Fri, 06 Mar 2026 16:46:50 +0000

Article URL: https://hatchet.run/blog/supertoast-tables

Comments URL: https://news.ycombinator.com/item?id=47277420

Points: 56

# Comments: 12

Tove Jansson's criticized illustrations of The Hobbit (2023)

abelanger — Fri, 27 Feb 2026 16:17:53 +0000

Article URL: https://tovejansson.com/hobbit-tolkien/

Comments URL: https://news.ycombinator.com/item?id=47182284

Points: 223

# Comments: 123

Escaping Misconfigured VSCode Extensions (2023)

abelanger — Fri, 20 Feb 2026 20:39:06 +0000

Article URL: https://blog.trailofbits.com/2023/02/21/vscode-extension-escape-vulnerability/

Comments URL: https://news.ycombinator.com/item?id=47093604

Points: 13

# Comments: 0

New comment by abelanger in "Building a TUI is easy now"

abelanger — Sat, 14 Feb 2026 17:08:19 +0000

Author here - I'm also generally skeptical of coding agents, but with the right problem domain and approach they can produce quality output when paired with humans. There was a point in time in the chess world where computer + human was stronger than computer or human alone. I think we're in that era for a handful of applications. Not for things like kernels, browsers, or databases.

> Besides, who is going to maintain that code?

I maintain the code. If Claude gets sunset tomorrow, I'll still be able to maintain and write it - I've already rewritten parts of it.

You could make the same argument for a team member leading a project that you've worked on. Is that code forever required to be maintained by one team member?

Previously the overhead of ensuring code quality when the development process was driven by Claude Code was greater than just writing the code myself. But that was different for this project.

New comment by abelanger in "Building a TUI is easy now"

abelanger — Sat, 14 Feb 2026 16:53:44 +0000

Hi, thanks! To be clear, the demo there is merely a WASM-based Ghostty build which is rendering the TUI on a web page, just so people could try it out without needing to install anything. The actual TUI runs in your terminal. I'm guessing it's the WASM side of things causing the fans to spin, which you wouldn't see locally.

New comment by abelanger in "Building a TUI is easy now"

abelanger — Sat, 14 Feb 2026 01:06:01 +0000

Hi everyone, I enjoyed building this TUI for myself and wanted to write down how I did it. I appreciate all the thoughts and feedback! The web app is our main investment, but I think there's a slice of developers who really like to interact with TUIs, so I'm going to keep working on it.

For the demo at https://tui.hatchet.run, to answer some messages asking about it: I built this with the fantastic ghostty-web project (https://github.com/coder/ghostty-web). It's been a while since I've used WASM for anything and this made it really easy. I deployed the demo across six Fly.io regions (hooray stateless apps) to try to minimize the impact of keystroke latency, but I imagine it's still felt by quite a few people.

New comment by abelanger in "Building a TUI is easy now"

abelanger — Fri, 13 Feb 2026 23:48:16 +0000

You're right - I'll remove that now until we can get it more performant or drop it altogether. This wasn't something we caught during testing. I appreciate the feedback!