How DBOS pushed Postgres LISTEN/NOTIFY to 60K writes/sec by batching notifies

Postgres LISTEN/NOTIFY is often dismissed as unscalable, but DBOS argues the real problem is a narrow, poorly documented bottleneck rather than a fundamental limit. When they built durable, low-latency streams by firing a NOTIFY from a trigger on every row insert, throughput stalled at about 2,900 writes per second even on a large instance — and tellingly, without saturating CPU, memory, or disk. The culprit is a global exclusive lock Postgres holds while committing any transaction that calls NOTIFY. Because notifications must be delivered in commit order, and commit order isn’t known until a commit finishes, Postgres serializes these commits behind one lock, defeating optimizations like group commit and forcing writes to happen one fsync at a time.

The fix hinges on a realization about how notifications are actually used: for streams and most pub/sub patterns, the NOTIFY isn’t the source of truth — it’s just a nudge telling a reader to go check the table where the real data lives. That means the notifications don’t need strict global ordering or durability. DBOS buffers notifications in memory and flushes them in periodic batch transactions, so the global lock is taken once per flush instead of once per write. Individual inserts then commit fast and benefit from group commit. To cover the gap where a crash could drop buffered notifications, readers add a low-frequency poll as a fallback, catching any writes that never triggered a wakeup.

The result is roughly 60,000 stream writes per second on a single server — a 20x gain — with 15–100ms latency and Postgres CPU fully saturated, meaning the database is doing real work rather than waiting on lock contention. The post also notes that an upcoming Postgres 19 patch does not remove this global lock; it only helps the separate case of many channels with per-channel listeners. Benchmark code is published on GitHub for anyone wanting to reproduce or adapt the approach.