Postgres LISTEN/NOTIFY gets a serious scaling reassessment
A detailed post arguing that Postgres LISTEN/NOTIFY actually scales well generated significant discussion, with commenters citing benchmarks reaching 60,000 notifications per second. The thread dug into a historical performance issue from the original implementation related to poor locking, which a later Postgres release addressed, and which an older widely-cited negative post had incorrectly characterized.
The key insight from the thread: 'scale' is a continuum, and 60K/s is simultaneously overkill for most applications and totally insufficient for others. The practical takeaway is that LISTEN/NOTIFY is a viable, low-complexity alternative to Redis pub/sub or a dedicated message queue for many production workloads, particularly for teams already running Postgres who want to avoid adding infrastructure dependencies.
The hard limit of 8,000 bytes per notification was flagged as a real constraint that hasn't changed, which matters for anyone trying to pass rich payloads through the channel. For those cases, using NOTIFY as a trigger and fetching the actual data from a table remains the standard pattern.
So what?
Founders running Postgres who have added Redis purely for pub/sub should re-examine that decision. LISTEN/NOTIFY is simpler, already in your stack, and scales further than most teams need. The 8KB payload limit is the main gotcha: design your notifications as triggers, not data carriers, and the constraint largely disappears.