DBOS: Postgres LISTEN/NOTIFY Hits 60K Writes/Sec
28 Jul 2026
The headline number
DBOS says it has optimized Postgres's built-in LISTEN/NOTIFY mechanism to sustain 60,000 stream writes per second on a single Postgres server, with latency in the 15-100ms range. That's a 20x improvement over the initial implementation, which topped out at just 2.9K writes/second.
For founders running lean infrastructure stacks, this is notable: LISTEN/NOTIFY is a native Postgres pub/sub feature, meaning teams could potentially get message-queue-like functionality without bolting on separate infrastructure like Kafka or Redis pub/sub.
What changed
The root cause of the original bottleneck was structural: committing a transaction that calls NOTIFY requires taking a global exclusive lock in Postgres. That lock created a hard ceiling on throughput in the initial implementation. DBOS's optimized solution works around this constraint to unlock the reported 20x gain.
The report does not specify exactly what optimizations were made, nor does it detail the hardware or server configuration used in the benchmark—so founders evaluating this for their own stack won't be able to replicate the exact conditions from the available facts.
The catch: durability and scale limits remain
Two risks are worth flagging before treating this as a drop-in replacement for dedicated queuing systems:
- Crash risk: if a process crashes while notifications are buffered, those notifications are permanently lost—they are never delivered. No mitigation strategy or buffering mechanism details are provided.
- Lock ceiling persists for now: the global exclusive lock issue isn't fully resolved. A Postgres patch addressing it is planned for Postgres 19, a future release with no confirmed date.
A single-source benchmark
All performance figures in this report come from DBOS itself, and have not been independently verified according to the available facts. There's also no comparison against alternative messaging systems, so it's unclear how this 60K writes/second figure stacks up against, say, Kafka or Redis pub/sub in equivalent conditions.
Why founders should care
- If these numbers hold up under independent testing, Postgres-native pub/sub may become viable for higher-scale use cases than founders previously assumed—potentially reducing the need to introduce and maintain separate messaging infrastructure early on.
- Teams already running Postgres could plausibly simplify their stack by leaning on LISTEN/NOTIFY instead of adding a message queue, assuming the reported throughput generalizes to their workload.
- The crash-related data loss risk means this is likely unsuitable for critical, durability-sensitive workloads without additional safeguards—something to weigh before committing architecture decisions.
- The upcoming Postgres 19 patch suggests further performance gains may be on the horizon, which could be a reason to delay major infrastructure bets tied to LISTEN/NOTIFY until that release lands.
- Given the single-source nature of these benchmarks, founders would be prudent to seek independent validation before making infrastructure decisions based solely on these figures.
Bottom line
A 20x throughput jump on a widely-used, already-installed Postgres feature is the kind of result that could meaningfully lower infrastructure complexity for early-stage teams—if it holds up under scrutiny. For now, treat it as a promising signal rather than a proven benchmark, and weigh the crash-related durability risk carefully against your workload's tolerance for lost messages.