Postgres LISTEN/NOTIFY actually scales
Points and comments are a snapshot, not live.
Postgres LISTEN/NOTIFY can scale to 60,000 notifications per second with application-side batching.
The article demonstrates that Postgres LISTEN/NOTIFY reaches 60,000 notifications per second on a 96-core server, contrary to prior claims it does not scale. The key optimization is application-side buffering and batch sending of notifications rather than sending them in every transaction. A Postgres 19 patch addresses a related issue but does not remove the global lock or fix the bottleneck observed. The experiment saturated Postgres CPU, indicating hardware limits rather than contention were the bottleneck.
The author notes that the 8,000-byte notification payload limit remains, which can be a constraint for certain use cases.
What commenters are saying
Commenters split into those who find LISTEN/NOTIFY sufficient for many use cases (cache invalidation, moderate throughput) and those who note real limitations. A key correction: the original blog post that claimed LISTEN/NOTIFY doesn't scale has been updated to note that the Postgres 19 commit fixed its specific bottleneck, though the DBOS article argues the global lock remains.
Several commenters note the hard 8,000-byte payload limit remains a constraint for some use cases. Others emphasize the value of NOTIFY's tight database integration and simplicity compared to adding another service like MQTT or Redis for moderate loads.