Going to create a PR into https://github.com/knobiknows/all-the-bufo later today.

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

Points: 16

# Comments: 2

    gh pr review  --approve
    gh pr merge  --squash --delete-branch

We have very different ways of approaching the harder problems; some of the clues are easier for someone with a formal CS/engineering background, but others just require a better memory of the different constraints, and she's much better at building a tagging system around those constraints.

Previously launched here: https://news.ycombinator.com/item?id=43923843

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

Points: 2

# Comments: 1

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

Points: 165

# Comments: 113

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

Points: 2

# Comments: 0

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

Points: 3

# Comments: 0

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

Points: 2

# Comments: 0

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

Points: 2

# Comments: 0

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 product 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: I'm trying something different this time. `ssh hatchet-jobs.com`

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!)

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

Points: 1

# Comments: 0

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

Points: 2

# Comments: 0

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

Points: 1

# Comments: 0

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

Points: 36

# Comments: 9

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)

> 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.

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.

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

Points: 523

# Comments: 240

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!)