You’ve probably been told to avoid Postgres LISTEN/NOTIFY. The whisper network says it’s a toy feature, fine for a hobby project but completely useless the moment real traffic hits. So, you nod, spin up a Kafka cluster, and add another piece of distributed infrastructure to your stack.
But what if the whisper network is wrong? What if the feature you dismissed as unscalable can actually handle over 60,000 notifications per second?
Recent benchmarks prove that Postgres LISTEN/NOTIFY doesn’t just survive high throughput—it thrives in it. The myth that it falls apart under load is exactly that: a myth. But there’s a catch. The feature isn’t broken; the way we use it often is.
A notification system is not a message bus. If you treat it like one, it will break.
The real bottleneck isn’t Postgres. It’s architectural. Developers routinely misuse LISTEN/NOTIFY by stuffing massive JSON payloads into the notification itself. They hit the 8000-byte limit, clog the global queue, watch performance tank, and then blame the database.
The correct pattern is brutally simple: don’t send the payload. Send an ID. Let LISTEN/NOTIFY act as a lightweight doorbell. When it rings, your application goes back to the database to fetch the actual data. This respects the design constraints and turns a ‘fragile’ feature into an elegant, highly scalable signaling mechanism.
We’ve been conditioned to reach for external message queues at the slightest hint of an event-driven architecture. It’s a form of infrastructure masquerading as progress. But if your data already lives in Postgres, keeping the signaling there eliminates network hops, reduces operational overhead, and drastically simplifies your system.
Most teams don’t need a distributed log; they just need a reliable doorbell. Stop building a post office when all you need is a knock on the door.
If you’re building event-driven systems on Postgres, it’s time to rethink your defaults. You can confidently use LISTEN/NOTIFY for high-throughput signaling without adding Kafka, RabbitMQ, or Redis to your infrastructure. Just respect the limits. Send the ID, not the kitchen sink.
FAQ
Q: But what about the 8000-byte payload limit?
A: That's a feature, not a bug. If you're hitting the 8000-byte limit, you're doing it wrong. Send a lightweight ID in the notification and let your app fetch the actual data from the database. LISTEN/NOTIFY is a doorbell, not a delivery truck.
Q: When should I actually use LISTEN/NOTIFY?
A: Use it for signaling and triggering workflows within a Postgres-centric stack. If your data already lives in Postgres, keeping the event notification there eliminates unnecessary network hops and external dependencies.
Q: Is Kafka dead then?
A: No, but your need for it probably is. Kafka is a distributed log built for massive, multi-consumer data streaming. Most applications just need a reliable notification system. Don't pay the operational tax of Kafka if Postgres already solves your problem.