April 18, 2026
Tick-tock, queue shock
PgQue: Zero-Bloat Postgres Queue
Database queues are back; fans cheer, skeptics cry 'bloat' and ask about 2‑second lag
TLDR: PgQue revives a classic design to run queues directly inside Postgres with a simple SQL install and promises stability over months, trading speed for seconds-level delay. Commenters split between “finally, no Kafka/RabbitMQ” and “a DB isn’t a queue,” with extra heat over confusing latency claims and “zero bloat” skepticism.
Old-school tech with new-school swagger: PgQue revives a 2009-era Postgres queue idea and ships it as a single SQL file that runs on basically any hosted database. The pitch is flashy: no add‑ons, no helper service, and “zero bloat” thanks to batch snapshots and table rotation instead of row‑by‑row deletion. Translation for non‑DB folks: it tries to keep things fast and tidy even after months of heavy use.
Cue the comments gladiator pit. Purists like cout roll their eyes at the “zero bloat” line—“a queue inside a database is still bloat to me.” Meanwhile, pragmatists like odie5533 are hyped to skip running big, cranky message systems like Kafka or RabbitMQ: “just use Postgres, thanks.” The real knife‑fight? Latency. PgQue admits delivery is often measured in seconds, not milliseconds, and saberd immediately pounces: “I don’t understand the latency graph”—why does it show lightning‑fast consume time but 1–2 seconds end‑to‑end?
Armchair architects show up with lore. halfcat breaks down three queue styles and praises PgQue’s failure mode: if a worker dies, the table grows instead of falling into a “VACUUM death spiral.” Others just hit “Cool” and move on. Meme watch: “2009 called, it wants its queue back,” versus “No daemons, just vibes.” Whether you’re hugging Postgres tighter or clutching your Kafka clusters, this drop has everyone counting tick‑tocks—and takes.
Key Points
- •PgQue revives the Skype-era PgQ queue architecture as a pure SQL solution for modern PostgreSQL (14+).
- •It avoids bloat by using snapshot-based batching and TRUNCATE-based table rotation instead of per-row DELETE/UPDATE.
- •No extensions, daemons, or server restarts are required; works on managed Postgres providers like RDS, Cloud SQL, AlloyDB, Supabase, and Neon.
- •PgQue prioritizes stability under sustained load and ACID semantics, trading default latency measured in seconds rather than milliseconds.
- •Feature comparison shows built-in retries, dead letter queue, language-agnostic SQL API, fan-out consumers, and zero-bloat behavior versus alternatives.