Mechanics: what actually travels the wire

Four lessons of architectures, one unexamined phrase: the leader "streams its changes." Streams what, exactly? The answer splits into three formats with very different failure modes — and then the cloud adds a fourth trick where almost nothing travels at all.

Statement, WAL, or logical?

Statement-based: ship the SQL text itself and re-execute it on the replica. WAL / physical: ship the write-ahead log — the byte-level disk changes ("page 4711, offset 32, these bytes"). Logical / row-based: ship the effect — "row with id=7: column paid_at changed from NULL to this value." The differences stop being abstract the moment your SQL contains anything nondeterministic:

Scorecard. Statement-based is compact but broken by nondeterminism (NOW(), RANDOM(), sequences, triggers) — MySQL kept it for years with band-aids, modern defaults have moved on. WAL shipping is exactly faithful and cheap for the primary (the WAL exists anyway — it's how the database survives its own crashes; replication just mails it out), but bytes-on-disk coupling means primary and replica must run the same version on the same architecture, complicating upgrades. Logical decouples: cross-version, cross-engine, filterable per table — the format of PostgreSQL logical replication and MySQL row-based binlog. Its cost: one statement touching 10M rows becomes 10M row events.

Logical's superpower: CDC

Because logical events say what changed in engine-neutral terms, anything can subscribe — not just replicas. That's change data capture: tools like Debezium tail the log and feed every insert/update/delete into Kafka, from which you hydrate search indexes, caches, warehouses, and audit trails. The pattern matters because it replaces two bad habits: dual-writes from the app ("write to Postgres and Typesense" — which drift the moment one write fails) and polling (SELECT ... WHERE updated_at > ?, which misses deletes entirely). The database's own log becomes the single ordered truth, and every downstream copy is just another replica in spirit.

The cloud's fourth trick: replicate almost nothing

Aurora's observation: if the WAL fully determines the database, why ship whole modified pages to replica servers at all? Detach storage into a shared, distributed layer — 6 copies across 3 AZs — and have compute nodes write only tiny log records into it. Writes need 4/6 storage copies (a quorum — Lesson 3's arithmetic, applied to disks); reads need 3/6. Read replicas share the same storage, so "replication lag" collapses to cache-invalidation time, typically ~10–20ms.

The map: every service, classified

Check yourself