Postgres LISTEN/NOTIFY Achieves 60K Writes/Second at Scale
Original: Postgres LISTEN/NOTIFY actually scales
Why This Matters
Demonstrates Postgres can serve as a scalable streaming backend, reducing reliance on dedicated message brokers.
DBOS engineer Peter Kraft published findings showing Postgres LISTEN/NOTIFY can sustain 60,000 stream writes per second on a single server with millisecond latency, overturning the common belief that the feature does not scale.
DBOS published a technical blog post on July 24, 2026, detailing how the team optimized Postgres LISTEN/NOTIFY-backed streams to achieve 60,000 writes per second on a single Postgres server with millisecond-scale latency. The post, written by engineer Peter Kraft, directly challenges a widely-cited claim that LISTEN/NOTIFY does not scale.
The team initially built a streaming system using a trigger that fired a NOTIFY call each time a new row was inserted into a streams table — suitable for use cases such as LLM response token streaming. This naive implementation was correct and low-latency but bottlenecked at only 2,900 writes per second, without visibly exhausting CPU, memory, or IOPS.
The root cause was identified as a global exclusive lock that Postgres acquires when committing a transaction containing a NOTIFY call. This lock is a known but poorly documented behavior that serializes all concurrent NOTIFY operations. The team developed optimizations to work around this bottleneck — batching notifications and reducing lock contention — ultimately achieving more than 20x throughput improvement over the naive baseline.
The post concludes that LISTEN/NOTIFY's scalability issues stem from unintuitive behavior, not a fundamental architectural limit, and that with proper optimization it remains a viable tool for durable pub/sub and low-latency streaming built entirely on Postgres.