Hacker News: KraftyOne

This is something we mention in the third section of the article: dead tuples and autovacuum caused real performance hits, which we (partially) mitigated through index optimization (minimizing the number and size of indexes, and making indexes partial).

PgQue is a really interesting system! However, its semantics are quite a bit more similar to Kafka than to a job queue, which is good for some workloads and not for others. For example a truncation-based deletion system is fast but inflexible, and not suitable for a job queue system because a single long-running job (and DBOS supports workflows that run for months) can block truncation.

Making Postgres queues scale

KraftyOne — Thu, 30 Jul 2026 18:39:32 +0000

Article URL: https://www.dbos.dev/blog/making-postgres-queues-scale

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

Points: 128

# Comments: 34

New comment by KraftyOne in "Postgres LISTEN/NOTIFY actually scales"

KraftyOne — Fri, 24 Jul 2026 20:44:37 +0000

The core optimization is to buffer notifications in-memory and send them in a batch instead of sending them as part of every transaction. So that's a general-purpose optimization for Postgres apps using LISTEN/NOTIFY.

New comment by KraftyOne in "Postgres LISTEN/NOTIFY actually scales"

KraftyOne — Fri, 24 Jul 2026 20:30:18 +0000

If you mean the optimizations coming in Postgres 19, the original post addresses this:

> As an aside, there’s been some online discussion of a Postgres patch (https://github.com/postgres/postgres/commit/282b1cde9dedf456...) related to this issue. This patch (to be released in Postgres 19) does not remove the global lock or fix the bottleneck we observed. Instead, it optimizes the narrower case where there are many notification channels and each listener is waiting only on a specific channel.

New comment by KraftyOne in "Postgres LISTEN/NOTIFY actually scales"

KraftyOne — Fri, 24 Jul 2026 20:18:22 +0000

To be clear, it's not a custom patch to pg itself, but an application-side buffering and batching optimization.

Postgres LISTEN/NOTIFY actually scales

KraftyOne — Fri, 24 Jul 2026 19:05:53 +0000

Article URL: https://www.dbos.dev/blog/postgres-listen-notify-scalability

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

Points: 373

# Comments: 84

Just Use Postgres for Job Queues

KraftyOne — Thu, 16 Jul 2026 18:32:07 +0000

Article URL: https://www.dbos.dev/blog/making-postgres-queues-scale

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

Points: 7

# Comments: 0

New comment by KraftyOne in "Postgres transactions are a distributed systems superpower"

KraftyOne — Fri, 03 Jul 2026 02:03:09 +0000

Outbox's power is that it turns an atomicity problem into an idempotency problem. You atomically write to the outbox, then you have an idempotent "workflow" that processes events from the outbox. This turns "at most once" semantics (where an event could be dropped entirely) to "at least once" semantics (where the event processing could run multiple times). For many systems, that's a big improvement.

New comment by KraftyOne in "Postgres transactions are a distributed systems superpower"

KraftyOne — Fri, 03 Jul 2026 00:38:02 +0000

You still need idempotency for side effects outside your database, that's true (and fundamental to durability). But now you get exactly-once semantics for operations on your database, which can be quite valuable if your workflow performs many such updates or they're particularly complicated or stateful.