Physical replication copies the write-ahead log and applies it byte for byte, producing an identical copy of the whole database. Simple, efficient, and inflexible — the target must run the same version, hold everything, and cannot be written to.
Logical replication decodes those log records into row-level changes and streams those instead. The target can be a different version, hold only some tables, have different indexes, and accept its own writes.
What changed in 2026
- Cross-version upgrades via logical replication became standard. The near-zero-downtime major upgrade path drove adoption.
- Change data capture pipelines matured. Streaming database changes into other systems became routine integration.
- Slot monitoring became a required practice. Disk-full incidents from abandoned slots made it a standard alert.
- Schema change handling stayed manual. DDL still does not replicate, and tooling only partially compensates.
What it enables
| Capability |
Physical |
Logical |
| Replicate a subset of tables |
No |
Yes |
| Target on a different version |
No |
Yes |
| Target accepts its own writes |
No |
Yes |
| Different indexes on the target |
No |
Yes |
| Replicate into a different system |
No |
Yes |
| Efficiency |
Higher |
Lower |
| Operational simplicity |
Higher |
Lower |
The version-independence row is what makes near-zero-downtime major upgrades possible: replicate from the old version to a new one, let it catch up, then switch traffic. Downtime is the switch rather than the upgrade.
The different-system row is what makes change data capture work — streaming changes into a search index, a warehouse, or an event bus.
Two things that catch people
Schema changes do not replicate. DDL is not part of the change stream. Add a column on the source and the target does not get it — and once the source starts sending rows with that column, replication breaks.
The discipline is applying schema changes on the target first, then the source, and doing so in a compatible order. That is the expand and contract pattern applied across a replication boundary, and it requires deliberate coordination.
Replica identity. To replicate an update or delete, the system must identify which row changed. That requires a primary key or another declared unique identity. A table without one can replicate inserts and will fail on updates and deletes.
This surfaces as replication working fine until the first update on a particular table, which makes it confusing to diagnose.
The slot that fills your disk
The most common operational failure with logical replication, and it takes down the source database.
A replication slot tracks how far a subscriber has consumed. The source retains write-ahead log segments until every slot has read past them.
If a subscriber goes away — the target is down, the pipeline is stopped, someone deleted the consumer but not the slot — the slot stops advancing. The source retains every log segment from that point onward, forever, and the disk fills.
This is a source-side outage caused by something wrong on the target side, which is why it surprises people. It is entirely preventable with monitoring.
Alert on slot lag and inactive slots. Both are simple queries against system views. Set a maximum retention where your engine supports it, so a stuck slot is dropped rather than filling the disk. And drop slots when decommissioning a subscriber — the forgotten slot after a removed consumer is the classic case.
Common mistakes
- No slot monitoring. Source disk fills; a source outage from a target problem.
- Forgetting to drop slots for removed subscribers. The most common cause.
- Assuming DDL replicates. It does not; coordinate schema changes.
- Tables without a replica identity. Updates and deletes fail.
- Using logical where physical would do. More flexibility, more operational surface.
- Writing to replicated tables on the target. Conflicts, unless you designed for them.
- Not planning sequence handling. Sequences do not replicate their state.
FAQ
Should I use logical or physical replication?
Physical for standby replicas and read scaling — simpler and more efficient. Logical when you need a subset, a different version, a writable target, or replication into another system.
Does it handle large transactions well?
A very large transaction is decoded and sent, which can produce a burst and delay. Some implementations stream in progress rather than waiting for commit, which helps considerably.
Can I replicate bidirectionally?
Possible and it introduces conflict resolution, which is a genuinely hard problem. Avoid unless you have a specific requirement and a clear conflict strategy.
What about sequences?
Sequence state does not replicate, so a target promoted to primary may reissue identifiers already used. Handle sequences explicitly during a switchover.
Where to go next
For the physical alternative and its lag characteristics, read replication lag and read replicas explained. For coordinating schema changes across the boundary, expand and contract migrations.