PgQue: Zero-Bloat Postgres Queue

PgQue revives the PgQ architecture, operating as a Postgres queue built entirely with pure SQL + PL/pgSQL, without any C extension or separate daemon.

• The core goal is to reduce dead tuples and VACUUM overhead, creating a queue with minimal performance degradation even under prolonged high load.
• The implementation is based on snapshot-based batching and TRUNCATE-based table rotation.
• It runs on Postgres 14+ and also supports managed Postgres environments like RDS, Aurora, Cloud SQL, AlloyDB, Supabase, Neon.
• Installation is possible with a single sql/pgque.sql file, and the default tick can be run via pg_cron or invoked directly by an external scheduler.
• Default latency is typically at the 1-2 second level due to tick and poll intervals, but send/receive/ack themselves are fast, at the microsecond level.

From a comparison standpoint, unlike typical SKIP LOCKED + DELETE/UPDATE-based job queues, PgQue focuses on avoiding accumulated bloat.

• Pros: zero bloat, fan-out consumer model, ACID transactions, operable purely via SQL
• Cons: not suited for ultra-low-latency dispatch, weak on per-job priority or typical worker framework features

It's a good fit for scenarios where event-driven fan-out, long-term operational stability, and a language-agnostic SQL API matter. Conversely, if you need sub-3ms latency, cron, unique jobs, or deep ecosystem integration, a traditional job queue is more suitable.

Roles are also separated.

• pgque_reader: for querying/debugging
• pgque_writer: API for producers/consumers
• pgque_admin: for operations and migration

The project is still early-stage, but it includes performance benchmarks, examples, and draft Python/Go/TypeScript clients, demonstrating real-world adoption potential.