Every production-grade relational database maintains a transaction log — an append-only file that records every committed change before (or as) it is applied to the actual data files. In PostgreSQL this is called the Write-Ahead Log (WAL); in MySQL it is the Binary Log (binlog); in Oracle it is the Redo Log. This log exists primarily for crash recovery and replication — CDC simply reads it for a third purpose.
Tapping the Wire
Log-based CDC works by reading this log file directly, rather than issuing SELECT queries against the live tables.
Here is what makes this approach fundamentally different from polling:
Low Impact: The CDC tool reads a sequential file from disk. It does not execute queries, does not acquire row locks, and does not consume database CPU for query planning. The overhead is comparable to adding one more read replica.
Complete capture: The log records every operation in commit order, including intermediate states within a transaction and every DELETE. Nothing is invisible.
Real-time delivery: As soon as a transaction commits and is written to the log, the CDC tool can read it — typically within milliseconds. End-to-end latency from database commit to downstream consumer is measured in seconds, not hours.
Ordering guarantees: Because the log is sequential, CDC preserves the exact order in which changes occurred. This matters when downstream systems need to reconstruct state correctly (e.g., you must process an INSERT before the UPDATE that follows it).
How Postgres Exposes the WAL for CDC
PostgreSQL provides a feature called logical replication slots. A replication slot is a named cursor into the WAL that the database maintains on behalf of a consumer. The database guarantees it will not discard WAL segments until the slot has consumed them — created with a single call to pg_create_logical_replication_slot(), naming the slot and the decoding plugin to use (typically pgoutput).
The pgoutput plugin decodes the raw binary WAL format into a structured logical stream that CDC tools can parse. This is the mechanism Debezium uses under the hood.
The Senior Concern: Replication Slot Lag
A critical operational risk: if the CDC consumer falls behind (crashes, is slow, or is paused), the replication slot prevents Postgres from cleaning up old WAL segments. The WAL directory grows unboundedly. In severe cases, this fills the disk and crashes the database. Every team running log-based CDC must monitor pg_replication_slots and set alerts on slot lag — computed as the byte gap between the current WAL position and each slot's restart_lsn.
If lag exceeds a threshold (e.g., 10 GB), the on-call engineer must investigate immediately. Some teams configure Postgres to automatically drop a lagging slot (max_slot_wal_keep_size) — this prevents disk exhaustion but means the CDC pipeline must perform a full re-snapshot to recover.