# PostgreSQL LISTEN/NOTIFY

13 Hacker News commenters recommended PostgreSQL LISTEN/NOTIFY and 10 criticized it, November 2025 to November 2026. It was recommended in 4 of 13 months.

**Verdict:** Simple built-in queue and pub/sub channel that people run in production without an extra service. Critics most often note no acknowledgements or retries, and doubt it scales under heavy load.

## Why people recommend it

- Scales well with listeners and load (3 comments): "It scales until the max it is possible, due the bottleneck being in the hardware, not in the database or i/o." ([source](https://news.ycombinator.com/item?id=49045775)) "now it scales well with the number of listening connections" ([source](https://news.ycombinator.com/item?id=47657724)) "It's basically impossible to out-scale it in that use case" ([source](https://news.ycombinator.com/item?id=49043567))
- Works in production at high volume (3 comments): "It is perfectly suitable for production workloads yet people still want to reach for more complicated solutions they don't need." ([source](https://news.ycombinator.com/item?id=47660693)) "We had a lot of success with LISTEN/NOTIFY when we paired it with a Rust graphql subscription broker." ([source](https://news.ycombinator.com/item?id=49044567)) "we use it for millions of events per day" ([source](https://news.ycombinator.com/item?id=47656785))
- Simple, no extra infrastructure (2 comments): "It is perfectly suitable for production workloads yet people still want to reach for more complicated solutions they don't need." ([source](https://news.ycombinator.com/item?id=47660693)) "listen/notify's simplicity outweighed the perf gains by WAL." ([source](https://news.ycombinator.com/item?id=45954070))
- Fears of production use overstated (2 comments): "Much of the FUD around using LISTEN/NOTIFY in production comes from people who have never done so." ([source](https://news.ycombinator.com/item?id=49041152)) "it's definitely not something that should be simply dismissed out of hand as an option" ([source](https://news.ycombinator.com/item?id=49040671))

## What people warn about

- Global lock can block writes (4 comments): "I read a blog post about it locking the entire database and causing problems" ([source](https://news.ycombinator.com/item?id=47179367)) "a single slow reader on one channel can block all writes to all channels" ([source](https://news.ycombinator.com/item?id=49048992)) "LISTEN/NOTIFY has an implementation which uses a global lock" ([source](https://news.ycombinator.com/item?id=46620803))
- Does not scale under load (3 comments): "it abdolutely doesn't scale and actually looses messages if the load is high enough" ([source](https://news.ycombinator.com/item?id=49045002)) "the post goes to show that LISTEN/NOTIFY does actually _not_ scale well" ([source](https://news.ycombinator.com/item?id=49055981)) "It also did not scale well." ([source](https://news.ycombinator.com/item?id=49043376))

## Alternatives hackers recommend

- [Apache Kafka](https://hackerapproved.com/p/apache-kafka.md): 53 recommend
- [NATS](https://hackerapproved.com/p/nats.md): 34 recommend
- [Redpanda](https://hackerapproved.com/p/redpanda.md): 17 recommend
- [RabbitMQ](https://hackerapproved.com/p/rabbitmq.md): 13 recommend
- [S2](https://hackerapproved.com/p/s2-lite.md): 9 recommend

## Cite as

Hacker Approved, "PostgreSQL LISTEN/NOTIFY", https://hackerapproved.com/p/postgresql-listen-notify/ (counts from 1,795,640 Hacker News comments, November 2025 to November 2026).