PgQue: Zero-Bloat Postgres Queue
by gmcabrita on 4/18/2026, 4:50:46 PM
https://github.com/NikolayS/pgque
Comments
by: saberd
I don't understand the latency graph. It says it has 0.25ms consumer latency.<p>Then in the latency tradeof section it says end to end latency is between 1-2 seconds.<p>Is this under heavy load or always? How does this compare to pgmq end to end latency?
4/18/2026, 10:12:55 PM
by: odie5533
Postgres durability without having to run Kafka or RabbitMQ clusters seems pretty enticing. May reach for it when I next need an outbox pattern or small fan out.
4/18/2026, 10:27:15 PM
by: cout
I think it's great that projects like this exist where people are building middleware in different ways than others. Still, as someone who routinely uses shared memory queues, the idea of considering a queue built inside a database to be "zero bloat" leaves me scratching my head a bit. I can see why someone would want that, but once person's feature is bloat to someone else.
4/18/2026, 10:02:29 PM
by: halfcat
So if I understand this correctly, there are three main approaches:<p>1. SKIP LOCKED family<p>2. Partition-based + DROP old partitions (no VACUUM required)<p>3. TRUNCATE family (PgQue’s approach)<p>And the benefit of PgQue is the failure mode, when a worker gets stuck:<p>- Table grows indefinitely, instead of<p>- VACUUM-starved death spiral<p>And a table growing is easier to reason about operationally?
4/18/2026, 11:50:30 PM
by: bfivyvysj
Cool
4/18/2026, 11:25:24 PM