Postgres LISTEN/NOTIFY actually scales

	Postgres LISTEN/NOTIFY actually scales(dbos.dev)
	328 points by KraftyOne 17 hours ago \| 62 comments
	tl;dr: Postgres LISTEN/NOTIFY hits a throughput ceiling (~2.9K writes/sec) because committing a transaction with NOTIFY requires a global exclusive lock held through fsync, serializing commits. DBOS worked around this by buffering notifications in memory and flushing them in batched transactions, with readers periodically polling as a fallback for missed notifications after crashes. This pushed throughput to 60K stream writes/sec on a single Postgres server with 15-100ms latency, saturating CPU rather than lock contention.
	HN Discussion: ~Scaling requirements vary widely; choosing tech with the right scaling factor matters more than raw throughput numbers ↑LISTEN/NOTIFY works well in practice when paired with smart architecture like fan-out brokers ↓The article omits critical details like how to allocate sequence numbers for consumer offset tracking ↑Real-world experience confirms LISTEN/NOTIFY has serious scaling problems, validating the need for workarounds ↓The article ignores prior corrections and hard limitations (like 8000-byte payload cap) that still constrain scalability