Postgres LISTEN/NOTIFY can scale — if your definition is specific
A DBOS post argues that PostgreSQL’s built-in notification system can handle far more than its reputation suggests. HN’s answer was a useful correction: scalability is never a yes-or-no property, and LISTEN/NOTIFY still has payload and semantics limits.
DBOS argues that LISTEN/NOTIFY can serve high-throughput workloads with the right design. The thread accepted the measurement but resisted the headline, noting that its 8KB notification payload limit and delivery semantics define where it fits.
The valuable takeaway is architectural rather than tribal: use notifications to signal durable rows or work, not to pretend they are an unrestricted message bus. A system that handles 60,000 events per second may be excessive for one team and inadequate for another.
“Scales” needs a workload attached
The DBOS article challenges the common assumption that PostgreSQL LISTEN/NOTIFY is only suitable for tiny workloads. Its point is useful: built-in database primitives are often dismissed before teams measure their actual bottleneck.
HN’s correction was equally useful. A commenter pointed to the 8KB notification payload cap and explained why transient, larger events may not map neatly to a database row. Another put the core issue crisply: scale is a continuum. A rate that is several orders of magnitude beyond one product’s needs can still be several orders too small for another.
That makes the design rule clearer. Let a notification identify or wake work that is stored durably, and treat the queue, batching, and consumer model as part of the system rather than as implementation trivia. The discussion did not refute the benchmark; it stopped the benchmark from becoming a universal claim.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Android’s proposed on-device ADB limits split convenience from physical security
Android may restrict on-device ADB, a feature that lets a phone connect debugging tools to itself. The argument is a classic platform trade-off: reduce a route an attacker with an unlocked device can automate, or preserve a capability that advanced users deliberately chose.