Postgres Teams Turn the Write Ahead Log Into a Real Time Event Bus

PostgreSQL's write-ahead log exists to guarantee durability and crash recovery. Teams now treat it as a real-time event bus, streaming changes into data lakes, dashboards, Spark jobs, and alerting systems while it stays the system of record. The pattern pulls application logic out of the database rather than pushing more in, and it's outrunning most teams' operational knowledge.

Diaa Radwan is a Data and AI Solution Engineer on the Global Black Belt team at Microsoft, working with financial services, telco, retail, and public sector across EMEA. He's spent more than 20 years across Red Hat, AWS, and Microsoft, with engagements running from Oracle migrations to generative AI. His recent talk at POSETTE 2026 covered building event-driven systems with PostgreSQL logical replication and Drasi. What he keeps seeing is enterprises discovering that the transaction layer they've ignored is where new architecture is happening.

"This is an important building block because it makes things easier downstream and in event-driven systems. Having that in a relational database like Postgres opens a new direction," Radwan says. "You can update a data lake, power dashboards, work with Spark, or build event-driven applications without all of those ETL jobs if WAL is done right."

The transaction log becomes an event source

Tooling around logical decoding has matured to where externalizing changes takes no custom work. Radwan points to pgoutput, wal2json, Debezium with Kafka, and Drasi, a CNCF sandbox project Microsoft donated that evaluates continuous queries against change feeds and triggers reactions.

"The whole extension ecosystem gives you an unlimited number of use cases. When you look at WAL, there are use cases built on top of the database that make cloud-native and event-driven applications easier, without all the logic living within the database," he says. "You can keep the database intact for a DBA and externalize that data in real time to other systems."

Radwan resists the idea that any one extension defines what the database is for. No single extension defines what Postgres is for: not PostGIS, not pgvector, and not whatever ships next. The momentum behind the ecosystem keeps adding more.

From scheduled queries to immediate action

The payoff shows up in workloads that used to run on a timer. A large order sitting unshipped, or a transaction that looks like fraud, no longer waits for a query firing every five minutes. It surfaces on commit.

CDC sidesteps a maintenance problem that's dogged Postgres shops for years. "The more that you use triggers, the more the code is in the database. It doesn't give you easy maintenance later on, and it will have limitations," Radwan says. Keeping logic outside the database leaves the schema legible to the people who maintain it.

Replication slots need supervision

None of this holds up without monitoring. WAL accumulation is the failure mode teams find late, usually when the storage bill or the outage forces it.

"WAL or the transaction log will not get into an amount of gigabytes that blocks reads and writes unless something is wrong with the consumer you have," Radwan says. "Without appropriate monitoring, things accumulate and become unusable." A stalled consumer is one trigger, but not the only one: failed archive commands, an oversized wal_keep_size, and orphaned replication slots each strand WAL the same way. Setting max_slot_wal_keep_size caps how much WAL a slot can retain, which is the practical guardrail against a single slow or dead consumer taking down the instance. Replication configuration and slot health are what keep it in check. He's blunt about where teams should spend. "If you're not paying for database licenses, you better pay for the training."

He sees the gap firsthand. Organizations run Postgres with replicas, skip the tuning, hit downtime, and decide the database isn't enterprise grade. Operational maturity trails adoption, and logical replication is newer than the confidence teams place in it.

AI speeds up deployment and skips the schema

AI cuts both ways. Oracle-to-Postgres assessments that traditionally take months compress dramatically with model assistance, which Radwan calls a clear positive. The other direction is messier.

"You find the schema that was created by AI is not covering the best practices, because it was just part of the story. It is not the main story," he says. "You don't have the right indices, you don't have the data types." Anyone can prompt their way to a deployed Postgres instance. Whether it survives production depends on choices made before the first row lands. His ask is modest. "Spend some time, not hours, not days, but a couple of minutes thinking about what this schema will be doing, how it will grow, what the access pattern is and how the queries are written."

The gap between what Postgres does and what teams know it does is what Radwan wants closed. Interest keeps climbing, the extension ecosystem outpaces anyone's ability to track it, and that makes awareness the constraint rather than capability.

"Awareness of what is possible is something we can do better as a community. A lot of people hear WAL, then they think replication, and that's it," Radwan says. "It's very difficult to say where Postgres is going in eighteen months. A company develops an extension, open sources it, someone in the community maintains it, and suddenly you have a whole spectrum of new features."