PgQue is not a new queue engine — it is a repackaging of PgQ, one of the longest-running Postgres queue architectures in production. Understanding where PgQ came from explains why PgQue chose to inherit rather than reinvent.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/NikolayS/PgQue/llms.txt
Use this file to discover all available pages before exploring further.
Timeline
| Year | Event |
|---|---|
| 2006 | PgQ started at Skype, inspired by Slony. Designed to handle messaging for hundreds of millions of users. |
| 2007 | Open-sourced as part of Skytools. First application: Londiste replication. |
| 2009 | Skytools 3: cascading queues, cooperative consumers. PgCon talk by Marko Kreen & Martin Pihlak (slides). |
| 2026 | PgQue: single-file PG14+ repackage for managed databases, with a modern API layer. |
Lineage
What PgQue adds
The original PgQ depends on a C extension (pgq) and an external daemon (pgqd), neither of which run on most managed Postgres providers. PgQue removes both constraints:
- Pure PL/pgSQL — no C extension, no
shared_preload_libraries, no provider approval - Single-file install —
\i sql/pgque.sqlin a transaction - Modern Postgres support — PostgreSQL 14–18, using
pg_snapshotandxid8 - pg_cron or pg_timetable — replaces the external
pgqddaemon for ticking - Modern API layer —
send,receive,ack,nack, DLQ on top of the raw PgQ primitives
The documented failure modes PgQue avoids
PgQue’s architecture choice was validated by real production incidents with SKIP LOCKED queues:- Brandur/Heroku (2015) — 60k backlog in one hour under MVCC pressure
- PlanetScale (2026) — death spiral at 800 jobs/sec with OLAP on the same instance
- River issue #59 — autovacuum starvation under sustained load
Attribution
PgQ: ISC license, © Marko Kreen / Skype Technologies OU.PgQue: Apache-2.0, © 2026 Nikolay Samokhvalov. See NOTICE.