DBOS has shown 60,000 writes per second on a single Postgres server with millisecond-scale latency, using an optimized version of Postgres's built-in LISTEN/NOTIFY messaging feature. The results, published July 24, 2026 in a blog post titled "Postgres LISTEN/NOTIFY Actually Scales," challenge a widely held belief that the feature breaks down under heavy use. DBOS

The belief originated from an earlier post by recall.ai titled "Postgres LISTEN/NOTIFY does not scale." That piece argued that Postgres's native publish/subscribe mechanism — a way for database processes to send messages to each other — was unsuitable for high-throughput workloads. DBOS's numbers push back on that conclusion, but with an important qualification: 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.

To understand the bottleneck, it helps to know how LISTEN/NOTIFY works. Postgres lets database sessions subscribe to named channels using LISTEN. When another session calls NOTIFY on that channel, all listeners receive the message. The system guarantees that notifications arrive in the same order as the transactions that sent them — a useful property for correctness, but one that comes at a cost.

When a transaction that includes a NOTIFY call commits, Postgres acquires a global exclusive lock — meaning no other transaction can proceed at the same time — and holds it until the transaction is fully committed and safely written to disk through a process called fsync. The lock exists to preserve commit ordering: Postgres maintains an internal queue of notifications whose order must match the order in which transactions committed. By serializing those transactions, the database ensures notifications are placed in the queue correctly.

The practical impact is severe. Under heavy load, every transaction issuing a NOTIFY must wait behind that lock during the commit-and-fsync window. DBOS's initial implementation, which used LISTEN/NOTIFY in a straightforward way, topped out at 2,900 stream writes per second on a single server. Beyond that point, the lock became the dominant source of latency, and adding more concurrent writers did not help because they all had to wait their turn at commit time.

DBOS's stream design stores each chunk of stream data as a new row in a dedicated table. Writers insert rows; readers use LISTEN on a channel to be notified when new data arrives, rather than repeatedly polling the table for changes. This is a familiar pattern 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 staying in the millisecond range, is the headline result. The 20x improvement comes from reducing the frequency and duration of lock contention during commit. 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 standard advice when throughput requirements exceed a few thousand events per second has been to abandon LISTEN/NOTIFY and move 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 specific contention pattern that straightforward usage creates.

The broader question is whether DBOS's optimizations generalize. 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 new infrastructure or first examine their own access patterns. A global exclusive lock held across fsync is a specific, diagnosable condition. 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. Whether the approach generalizes across all workloads and schema designs remains an open question that a single blog post cannot fully answer.

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?