PostgreSQL queues done right with PgQ | POSETTE: An Event for Postgres 2026

Learn how PostgreSQL queues can be implemented using PgQ. Alexander Kukushkin (Microsoft) demonstrates this in his talk “PostgreSQL queues done right with PgQ” at POSETTE: An Event for Postgres 2026. Abstract: Modern applications often rely on message queues - for background jobs, data pipelines, notifications, and event-driven architectures. Using something external like Kafka, Redis, RabbitMQ, etc increases operational complexity and introduces new failure modes. It all could be avoided by keeping a message queue in a database. Quick research on the internet shows that developers commonly are trying to engineer the database queue based on SELECT … FOR UPDATE SKIP LOCKED (available since 9.5). This approach works reasonably well under small load, and spectacularly falls apart if subscribers can’t keep up with publishing rate. PostgreSQL can do better, and in fact, it already did. PgQ is PostgreSQL extension that provides generic, high-performance lockless queue with simple SQL. In this talk, we start with why common SELECT … FOR UPDATE SKIP LOCKED approaches fall apart under load, and how PgQ quietly solved those problems a couple decades ago. Then we take a deep look at PgQ internals: snapshot-based event reads, transaction-ordered delivery, and how PgQ gets away with just a single index to achieve high throughput and consistency. Finally, we will discuss practical patterns for running PgQ on managed PostgreSQL services where this extension is typically not available. Alexander Kukushkin is better known in the PostgreSQL community as "the Patroni guy". Patroni is an open source tool for implementing PostgreSQL clustering and high availability. Besides Patroni, Alexander occasionally contributes to PostgreSQL and other open source projects and tools, usually Postgres related. Alexander is a Principal Software Engineer at Microsoft ► Video chapters: ⏩ 00:00 – Music & introduction ⏩ 00:26 – Agenda: queues, problems, PgQ ⏩ 01:15 – Why use in-database queues ⏩ 02: