DBOS has demonstrated 60,000 writes per second on a single Postgres server with millisecond-scale latency using optimized LISTEN/NOTIFY-backed streams, pushing past a scalability ceiling that had become received wisdom in parts of the engineering community. The results are detailed in a blog post titled "Postgres LISTEN/NOTIFY Actually Scales," published on July 24, 2026 on the DBOS website. DBOS

The post directly confronts a narrative that took hold after recall.ai published a piece titled "Postgres LISTEN/NOTIFY does not scale." That earlier post contributed to a widely-held belief that Postgres's built-in pub/sub mechanism is unsuitable for high-throughput workloads. DBOS's numbers challenge that conclusion, though the distinction matters: they did not find that LISTEN/NOTIFY scales out of the box. They found that the bottleneck is specific and, with the right design, avoidable.

The bottleneck is a global exclusive lock that Postgres takes during NOTIFY. When a transaction calls NOTIFY and commits, Postgres acquires the lock at the start of commit and holds it until the transaction is fully committed and flushed to disk via fsync(). The reason for the lock is ordering: Postgres guarantees that notifications are delivered in transaction commit order. To enforce that guarantee, the database maintains a global internal queue whose entries must match the commit order of the sending transactions. The exclusive lock serializes commits of transactions containing notifications, ensuring that commit order is defined ahead of time and that notifications can be correctly placed in the queue.

The practical consequence is severe. Under contention, every transaction issuing a NOTIFY stalls behind the lock during the commit-and-fsync window. DBOS's initial implementation, which used LISTEN/NOTIFY in a straightforward manner, could not sustain more than 2,900 stream writes per second on a single server. At that throughput, the lock becomes the dominant latency source, and adding concurrent writers does not help because they serialize at commit time.

DBOS's stream design uses a streams table where each stream chunk is stored as a new row. Writers insert rows into the table. Readers use LISTEN on a channel to block and wake up when new chunks arrive, rather than polling the table for changes. This pattern is familiar to anyone who has built event-driven systems on Postgres. The innovation is not in the pattern itself but in how DBOS restructured writes to avoid triggering the global lock on every notification.

The jump from 2,900 writes per second to 60,000 on the same single-server Postgres instance, with latency remaining in the millisecond range, is the headline result. The 20x improvement comes from reducing the frequency and duration of lock contention during commit, though DBOS's post does not describe every implementation detail of the optimization.

For teams building real-time or event-driven systems on Postgres, the finding reframes a common architectural decision. The default advice when throughput requirements exceed a few thousand events per second has been to move off LISTEN/NOTIFY entirely, typically to an external message broker such as Redis Streams, Kafka, or NATS. DBOS's results suggest that the ceiling is not inherent to the LISTEN/NOTIFY mechanism itself but to the contention pattern that naive usage creates.

Worth flagging: the distinction between "LISTEN/NOTIFY does not scale" and "LISTEN/NOTIFY as commonly used does not scale" is not academic. It determines whether engineers default to adding infrastructure or first examining their access pattern. A global exclusive lock held across fsync is a specific, diagnosable condition. Whether the optimizations DBOS applied generalize across all workloads and schema designs remains an open question that a single blog post cannot fully answer. The 60,000 writes-per-second figure was achieved on a specific workload with a specific stream design, and readers should treat it as an existence proof, not a universal benchmark.

That said, an existence proof is valuable. It shifts the burden of proof. The next time someone reaches for an external broker because "LISTEN/NOTIFY doesn't scale," the follow-up question is now better informed: at what throughput, under what contention model, and have you profiled the commit path?