DBOS claims 20-fold performance boost for Postgres LISTEN/NOTIFY
New technical findings from DBOS demonstrate that PostgreSQL’s notification system can handle 60,000 writes per second, challenging long-held beliefs about its scalability limits.
DBOS has published technical findings demonstrating that PostgreSQL’s LISTEN/NOTIFY functionality can be scaled effectively, achieving throughput rates significantly higher than previously thought possible. By implementing a strategy that buffers notifications in memory and flushes them in batch transactions, the company recorded 60,000 writes per second on a single PostgreSQL server. The system maintained latencies between 15 and 100 milliseconds during these benchmarks.
This performance represents a 20-fold improvement over the firm’s initial implementation, which was constrained to approximately 2,900 writes per second. The earlier bottleneck was caused by PostgreSQL taking a global exclusive lock during NOTIFY commits to guarantee notification order. This lock serialised transactions, preventing group commit optimizations and limiting throughput regardless of CPU or disk utilisation.
The root of the issue lies in how PostgreSQL ensures that notifications are sent in transaction commit order. To enforce this, the database stores outgoing notifications in a global internal queue. Because commit order is not defined until a transaction is fully committed and flushed to disk, the system requires a global lock to serialize these operations. This mechanism, while ensuring durability and order, creates a severe contention point for high-volume write workloads.
DBOS’s solution circumvents this lock by treating notifications as signals rather than sources of truth. The optimisation involves buffering notifications in memory and flushing them in batch transactions, which reduces contention on the global lock to only the moments when the buffer is cleared. This allows individual stream writes to proceed quickly, leveraging PostgreSQL’s standard optimizations. To address durability concerns introduced by this buffering strategy, the company implemented a fallback polling mechanism to ensure notification delivery in the event of process crashes.
While a patch planned for PostgreSQL version 19 will optimise cases with many notification channels, it will not remove the global lock or fix the specific bottleneck addressed by DBOS. Benchmarking code for the optimisation is available on GitHub at github.com/dbos-inc/dbos-postgres-benchmark. The results suggest that with the right architectural adjustments, PostgreSQL can support high-throughput, low-latency data streams without sacrificing reliability.
