Replication and WAL Articles

The 3 a.m. page was pg_wal at 100 percent on a healthy primary. The cause was a Debezium slot from a proof of concept eight weeks earlier, quietly pinning 380 GB of WAL nobody would ever read.

MySQL grew failover tooling around topology repair; PostgreSQL grew it around consensus and leases. Comparing orchestrator and group replication with Patroni and repmgr, honestly.

GTIDs make MySQL failover repointing almost trivial; replication slots make PostgreSQL WAL retention automatic but risky. A practitioner's comparison of the two position-tracking models.

Debezium tailing a MySQL binlog and a PostgreSQL logical decoding pipeline look similar from Kafka. Underneath, snapshots, schema changes, and retention fail in opposite ways.

MySQL replicates logical change events from the binlog; PostgreSQL streams physical WAL. That one design difference changes lag measurement, consistency guarantees, and what your replicas can be.

Both Aurora flavors share the same storage layer and carry very different databases on top. Here is how I compare them: feature deltas, the extension ecosystem, performance tests you should run yourself, and migration gravity.

A single unique violation on a logical replication subscriber can stall the stream and fill the publisher's disk with retained WAL. Here is how conflicts happen and how to recover.

Long analytics queries on our replica kept getting cancelled mid-run. Turning on hot_standby_feedback stopped the cancellations instantly — and then the primary started bloating. That trade is the whole story.

Write-heavy PostgreSQL systems usually fail through WAL pressure, checkpoint I/O, replication lag, or storage stalls. The fix starts with measuring the write path, not raising random knobs.

We scaled reads to a replica and started getting bug reports about data that 'disappeared' right after saving. The cause was replication lag, and the fix was being honest about which reads can tolerate it.