Physical versus logical replication

Physical replication ships the write-ahead log as it stands and replays it block by block, so the standby’s data files are identical to the primary’s and cannot diverge in any respect. Logical replication reads the same log through a decoder that turns it back into row-level changes, then applies those as ordinary statements on the other side. The subscriber is a separate database that happens to receive some of another one’s rows. Same source, almost no shared properties.

The constraint lists barely overlap

A physical standby copies the whole cluster or nothing. It must run the same major version, on the same architecture and page layout, and it is read-only for as long as it is a standby. In exchange it needs no configuration per table, it carries schema changes across without being told, and it is the thing you promote when the primary is gone.

A logical subscriber is per table and per publication. It can run a different major version, a different platform, and can be written to by other applications at the same time, which is what makes it the tool for an upgrade with minutes of downtime or a feed into a reporting database. The cost is a list of things it does not carry: schema changes, sequence values, and any update or delete on a table that has no way to identify rows. Large objects are outside it as well.

That last list is where projects go wrong. Nothing errors when a column is added on the publisher; the change simply does not arrive, and the subscriber keeps working until a statement references the column that is not there.

The setting that decides it before anything else

Physical replication works on a server out of the box. Logical does not, and the failure is immediate.

SELECT slot_name FROM pg_create_logical_replication_slot('analytics_feed', 'pgoutput');

ERROR:  logical decoding requires "wal_level" >= "logical"

The decoder needs information that the default log level does not record, and the server cannot add it retrospectively, so this is a restart and a decision taken in advance rather than a switch flipped during an incident. Raising the level also makes every write larger, which is the reason it is not the default. A cluster that might ever need a logical feed is therefore better configured for it from the start than converted under pressure.

Choosing, and then watching the right numbers

The choice is usually made by the constraint list above rather than by preference: a failover target is physical, a cross-version migration or a selective feed is logical. Both are then monitored through slots, and the failure modes differ enough that replication lag and slot health treats them separately. The marker each one depends on is a replication slot, and what the sender reports about how far each consumer has got is write, flush and replay lag.