PostgreSQL LISTEN/NOTIFY
Shares rank 5 of 19 message brokers by recommenders
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.
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.
23 people gave an opinion
- recommend it
- 13
- criticize it
- 10
- approval share
- 57%
Recommended in 4 of 13 months
- November 2025: recommended
- December 2025: not recommended
- January 2026: not recommended
- February 2026: not recommended
- March 2026: not recommended
- April 2026: recommended
- May 2026: not recommended
- June 2026: not recommended
- July 2026: recommended
- August 2026: recommended
- September 2026: not recommended
- October 2026: not recommended
- November 2026: not recommended (month in progress)
Why it doesn’t carry the badge
- 13 people recommend itNeeds 10 or more, met.
- 1.3 recommenders for every criticNeeds 2 to 1 or better, not met.
- Recommended in 4 of 13 monthsNeeds 4 or more, met.
The same three rules apply to every product, and the badge can’t be bought. How the badge works
What people say about it
The reasons people give, with the number of comments that give each one. Open a reason to read what they said.
Why people recommend it
Each mark is one comment
Scales well with listeners and load
“It scales until the max it is possible, due the bottleneck being in the hardware, not in the database or i/o.”
Comment from 25 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” “now it scales well with the number of listening connections”
Comment from 6 Apr 2026 in “Eight years of wanting, three months of building with AI” “It's basically impossible to out-scale it in that use case”
Comment from 25 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” Works in production at high volume
“It is perfectly suitable for production workloads yet people still want to reach for more complicated solutions they don't need.”
Comment from 6 Apr 2026 in “Eight years of wanting, three months of building with AI” “We had a lot of success with LISTEN/NOTIFY when we paired it with a Rust graphql subscription broker.”
Comment from 25 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” “we use it for millions of events per day”
Comment from 6 Apr 2026 in “Eight years of wanting, three months of building with AI” Simple, no extra infrastructure
“It is perfectly suitable for production workloads yet people still want to reach for more complicated solutions they don't need.”
Comment from 6 Apr 2026 in “Eight years of wanting, three months of building with AI” “listen/notify's simplicity outweighed the perf gains by WAL.”
Comment from 17 Nov 2025 in “Listen to Database Changes Through the Postgres WAL” Fears of production use overstated
“Much of the FUD around using LISTEN/NOTIFY in production comes from people who have never done so.”
Comment from 24 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” “it's definitely not something that should be simply dismissed out of hand as an option”
Comment from 24 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales”
What people warn about
Each mark is one comment
Global lock can block writes
“I read a blog post about it locking the entire database and causing problems”
Comment from 27 Feb 2026 in “You Just Need Postgres” “a single slow reader on one channel can block all writes to all channels”
Comment from 25 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” “LISTEN/NOTIFY has an implementation which uses a global lock”
Comment from 14 Jan 2026 in “I Love You, Redis, but I'm Leaving You for SolidQueue” - Comment from 27 Nov 2025 in “How/why to sweep async tasks under a Postgres table”
Does not scale under load
“it abdolutely doesn't scale and actually looses messages if the load is high enough”
Comment from 25 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” “the post goes to show that LISTEN/NOTIFY does actually _not_ scale well”
Comment from 26 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales” “It also did not scale well.”
Comment from 25 Jul 2026 in “Postgres LISTEN/NOTIFY actually scales”
Other message brokers people recommend
The four most recommended other message brokers, with the same counts for each, so you can compare like for like. The tick on each bar marks the 2 to 1 line the badge needs.
| Product | Recommend | Criticize | Approval | Months | Owned | Badge |
|---|---|---|---|---|---|---|
| Apache Kafka | 53 | 55 | 49% | 12 | — | — |
| NATS | 34 | 16 | 68% | 9 | 7.5 yrs3 owners | Approved |
| Amazon SQS | 18 | 14 | 56% | 8 | — | — |
| Redpanda | 17 | 4 | 81% | 7 | — | Approved |
| PostgreSQL LISTEN/NOTIFYThis page | 13 | 10 | 57% | 4 | — | — |
What people said
22 of the 25 comments that mention it, newest first. Each links to the original comment.
“the post goes to show that LISTEN/NOTIFY does actually _not_ scale well”
“a single slow reader on one channel can block all writes to all channels”
“why is there only an option for globally ordered NOTIFYs?”
“It scales until the max it is possible, due the bottleneck being in the hardware, not in the database or i/o.”
“it abdolutely doesn't scale and actually looses messages if the load is high enough”
“We had a lot of success with LISTEN/NOTIFY when we paired it with a Rust graphql subscription broker.”
“It's basically impossible to out-scale it in that use case”
“It also did not scale well.”
“Much of the FUD around using LISTEN/NOTIFY in production comes from people who have never done so.”
“it's definitely not something that should be simply dismissed out of hand as an option”
“the hard limit on 8000 bytes of data in a notification”
“It is perfectly suitable for production workloads yet people still want to reach for more complicated solutions they don't need.”
“now it scales well with the number of listening connections”
“we use it for millions of events per day”
“I read a blog post about it locking the entire database and causing problems”
“LISTEN/NOTIFY has an implementation which uses a global lock”
“Feels tidier till it becomes a bottleneck”
“they don’t have any mechanism for ACKs or retries”
“The longer I work the fewer legitimate use cases for LISTEN/NOTIFY I seem to find.”
“listen/notify's simplicity outweighed the perf gains by WAL.”
“It's a common misconception that the single queue is a poor design choice.”
“it performs way better than we would ever need”
Counts come from 1,795,640 Hacker News comments, November 2025 to November 2026. How we count. Report a mistake.