Two Replication Mechanisms, Not Two Flavors of the Same Thing
Before choosing between Postgres replication strategies, it is helpful to reference our companion video, which steps through the visual layout of these architectures. That video serves as a quick visual guide, but this article cuts straight to the underlying machinery.
We often talk about replication as if we are deciding between two minor configuration paths. That is a mistake. These features do not split on small details; they operate on entirely different architectural layers.
[ Physical Replication ]
Primary WAL Buffer ---> Ships Bytes ---> Standby Replays Bytes (Direct Disk Blocks)
[ Logical Replication ]
Primary WAL Buffer ---> Logical Decoding (PGOutput) ---> Ships SQL-Like Rows ---> Subscriber Runs SQL
Physical replication operates at the disk-block level. It reads the write-ahead log (WAL) and ships those raw physical bytes directly across the wire. The receiver writes those exact bytes to its own disk blocks. The target is a byte-for-byte twin of the source.
Logical replication operates at the row-level SQL layer. It runs a background worker to decode the WAL back into logical change events (such as this column in this table was updated to a new value). It publishes only the changes you explicitly select, at table granularity. This means you can replicate a subset of tables, or even a subset of rows using a publication filter (PostgreSQL 15+). Logical replication is not a cloned server; it is a continuous stream of discrete modifications.
Because logical replication unpacks the WAL into logical changes, it can cross major PostgreSQL versions, operating systems, and even CPU architectures. Physical replication, in contrast, ties you to identical binaries and block layouts—an exact clone, nothing less. That byte‑level fidelity makes physical replication indispensable for high‑availability setups where failover must produce an identical standby. Logical replication, however, thrives in data sharing, zero‑downtime migrations, and selective synchronization.
But logical replication comes with strings attached. It does not replicate DDL by default. If you create or alter a table on the primary, the changes will not automatically propagate; you must manually apply the same DDL on the subscriber. Sequences are not replicated natively (you run pg_dump --data-only to sync them initially or use an extension). Large objects and some internal system catalogs are also excluded. These gaps are not bugs—they follow from the decision to work at the row‑SQL level. The feature gives you control, but control requires management.
Physical replication, with its block‑by‑block shipping, avoids these object‑level headaches. Every schema change, every catalog update, every internal tweak lands on the standby because the WAL records the raw bytes of those changes. The price is rigidity: you cannot run a different major version, you cannot replicate only certain tables, and you cannot write to the replica (unless you move to a failover). The standby is a silent mirror.
When the Choice Becomes Clear
If you need a warm or hot standby for disaster recovery, physical replication is the default and often the only practical choice. It ensures the standby can take over immediately with zero data shape differences. If you are migrating from PostgreSQL 14 to 17 with minimal downtime, logical replication lets you run old and new side‑by‑side, streaming changes until the cutover. If you feed a data warehouse with a curated slice of operational tables, logical replication with publications is the cleanest path. And if you are building a multi‑master‑like setup (though not native multi‑master), logical replication’s ability to subscribe to multiple publishers gives you a building block.
Neither replication strategy is a silver bullet. They operate at different abstraction levels and solve different categories of problems. The real skill is recognizing which layer matches your tolerance for complexity and your need for flexibility. Once you see that physical replication preserves physical identity, while logical replication trades away identity for logistical freedom, the decision writes itself.