November 16, 2025
Knock-knock, it’s database drama
Listen to Database Changes Through the Postgres WAL
Slow alerts roasted, the database’s secret diary steals the show
TLDR: The post shows how to tap Postgres’s change log (WAL) for real-time updates without slowing apps. Comments clash over NOTIFY’s limits, defend its nuances, and boost [Debezium](https://debezium.io/) + Kafka; it matters for faster systems and fewer lost messages in high-traffic databases.
The post kicks off with a groaner (No-bell prize, anyone?) and then drops the real tea: ditch Postgres’s crowded NOTIFY lane and eavesdrop on the Write-Ahead Log (WAL)—basically the database’s secret diary of every change. The crowd went full popcorn mode. One camp is furious that NOTIFY runs on a single, slow queue, asking why it’s designed like a DMV line on a Monday. Another camp pushes back: commenter JoelJacobson argues the “100,000 notifications” horror story is only true if all messages are different, adding nuance to the panic. Meanwhile, nostalgia kicks in as veterans recall SQL Server’s “transactional log shipping,” proving this isn’t a new trick, just a new stage. Enter the Debezium hype train: fans yell “just use Debezium with Kafka,” turning the thread into Team DIY WAL vs Team Kafka. And there’s intrigue—Joel hints they’re “currently worki…” on the bottleneck, which set off speculation that Postgres might get a fix. The vibe: pg_notify got roasted for size limits and dropped messages, WAL got crowned for replication, backups, time-travel restores, and real-time change listening (a.k.a. CDC—Change Data Capture), all without app code changes. The meme of the day? “Your alerts stuck in a single-lane queue” vs “WAL whisperers sipping tea while changes stream in.”
Key Points
- •PostgreSQL’s NOTIFY/pg_notify uses a single notification queue, causing contention and performance degradation under high throughput.
- •NOTIFY has an 8000-byte payload limit, lacks listener acknowledgment and retries, and can emit many notifications via triggers in large transactions.
- •The PostgreSQL Write-Ahead Log (WAL) records all changes and allows deferring data page writes, improving throughput and enabling crash recovery.
- •WAL supports replication, online/streamed backups, and point-in-time recovery (PITR).
- •Listening to the WAL enables real-time Change Data Capture (CDC) for notifications and audit logs without modifying application code; the author plans to demonstrate this using Elixir.