Physical Replication

When an airline needs a backup flight recorder, they do not build a device that "interprets" the original's data and reconstructs it. They make a bit-for-bit copy. If the original dies, the copy is identical in every way.

Physical replication follows the same philosophy. It does not interpret changes. It does not decode them into logical operations. It copies the raw bytes, the actual disk blocks, from the primary to the replica. The result is an exact binary clone. Same data files, same indexes, same internal page layout. If you looked at the disk contents of the primary and replica with a hex editor, they would be identical.

This is the workhorse of high-availability database setups. When your primary dies and you need to failover in seconds, not minutes, not hours, physical replication is what makes that possible. The replica is already an exact copy, so promoting it to primary is nearly instantaneous.

Amazon RDS uses physical replication for every Multi-AZ deployment. When you check that "Multi-AZ" box on an RDS Postgres instance, AWS creates a synchronous physical replica in a different availability zone. If the primary fails, RDS promotes the replica in under 60 seconds. Neon, the serverless Postgres provider, also uses physical replication internally for its pageserver architecture.

In Postgres, physical replication works through the Write-Ahead Log (WAL).

Every change to the database (inserts, updates, deletes, index modifications, even vacuum operations) first gets written to the WAL as a sequence of binary records. The WAL is a sequential log of raw page modifications. "Change byte 4096 through 8192 of file base/12345/67890 to these values."

Physical replication streams these WAL records from the primary to the replica. The replica applies them verbatim. It writes the same bytes to the same locations in its own data files. No interpretation, no translation, no transformation.

This is why physical replicas must run the same major Postgres version on the same platform. A WAL record from Postgres 14 on Linux x86_64 contains binary references to data page layouts specific to that version and architecture. A different version would lay out data differently, and the raw bytes would not make sense.

What you get:

• Exact binary copy of the entire database cluster (all databases, all schemas, all tables)
• Read-only queries on the replica (hot standby mode)
• Sub-second failover when the primary dies
• Minimal overhead on the primary (just streaming its existing WAL)
• DDL changes replicated automatically (they are just WAL records too)

What you do not get:

• Selective replication (it is all or nothing, every database in the cluster)
• Cross-version replication
• Write capability on the replica (it is strictly read-only)
• The ability to have different indexes or configurations on the replica