Zero Bloat Postgres Queue | Scaling Postgres 416

Scaling Postgres15mMay 10, 2026

Get the full intelligence

Search transcripts, export clips, track mentions, and explore all topics from “Zero Bloat Postgres Queue | Scaling Postgres 416” inside PodZeus.

AI-Generated Summary

PostgreSQL's traditional job queues, reliant on `FOR UPDATE SKIP LOCKED`, often spiral into performance decay due to dead tuples and index bloat under load—what the host calls the 'Q Spiral of Death.' But a new tool called PGQ, built by Nick from Postgres FM, offers a radical alternative: a zero-bloat queue that avoids updates and deletes entirely. Instead of modifying rows, PGQ uses snapshot-based batching and a rotating table system with three tables cycling through truncate operations. This design eliminates dead tuples, maintains consistent performance even at scale, and works on managed cloud Postgres. The tradeoff? Latency: jobs are processed at 50–150ms intervals by default (10 ticks per second), making it unsuitable for sub-millisecond needs but ideal for stable, high-throughput systems. The episode also covers broader ecosystem updates, including PG Backrest’s revival through community funding, PGX Backup as a potential fork, Postgres 19’s expanded multi-exact member support, and Figma’s new connection pooler PG-Keeper built to overcome PG Bouncer’s limitations. Finally, it shares practical disaster response rules and insights into how PostgreSQL committers are selected.

Key Takeaways
1

Use PGQ’s snapshot-based batching and truncate rotation to eliminate dead tuples and prevent performance decay in high-load queues.

2

PGQ trades sub-millisecond dispatch for stability—jobs are processed every 50–150ms by default due to 10 ticks per second.

3

Avoid the 'Q Spiral of Death' by replacing `FOR UPDATE SKIP LOCKED` with a design that never updates or deletes queue rows.

4

PGQ works on managed Postgres clouds and requires only a periodic ticker (e.g., via PG-Cron) to function.

5

Figma built PG-Keeper to overcome PG Bouncer’s single-threaded limitations and lack of observability and traffic prioritization.

…and 3 more takeaways available in PodZeus

Chapters
0:00
5 min

The Problem with Traditional Postgres Queues

The episode opens by highlighting the performance decay caused by `FOR UPDATE SKIP LOCKED` in high-load scenarios, leading to the 'Q Spiral of Death' due to dead tuples and index bloat.

5:00
5 min

Introducing PGQ: Zero Bloat Queue Architecture

PGQ essentially has no dead tuples because it never updates or deletes.

Highlight
10:00
5 min

Ecosystem Updates: PG Backrest, PGX, and PG-Keeper

I understand that is a nuisance. They also couldn't prioritize any particular traffic.

Highlight
High-Impact Quotes
PGQ essentially has no dead tuples because it never updates or deletes.
Host2:07
Viral: 85.0
Jobs are going to have a 50 to 150 millisecond latency.
Host3:00
Viral: 78.0
The only changes that happen at this table are the inserts of the new jobs coming in.
Host5:51
Viral: 72.0
Speakers

Host

Host Name
Topics Discussed
zero bloat postgres queue95%pgq implementation90%q spiral of death88%snapshot based batching85%pg-backrest revival75%pg-keeper connection pooler70%postges 19 multi-exact65%
People & Brands

PGQ

product

12xPositive

Nick

person

5xNeutral

pg-backrest

product

4xPositive

Figma

organization

3xPositive

PG-Keeper

product

3xPositive

David

person

3xNeutral

PGX Backup

product

2xNeutral

Postgres FM

organization

2xNeutral

CyberTech

organization

2xPositive

Kristoff

person

1xNeutral

Get the full intelligence

Search transcripts, export clips, track mentions, and explore all topics from “Zero Bloat Postgres Queue | Scaling Postgres 416” inside PodZeus.

Start discovering podcast insights today

Start with a 7-day trial and explore a growing catalog of popular podcasts. No credit card required.

No credit card required • 7-day trial • Cancel anytime