{"post":{"slug":"logical-replication-explained-2026","title":"Logical Replication: Replicating Changes, Not Blocks","excerpt":"Physical replication copies a byte-identical database. Logical replication streams row changes, which makes selective replication and cross-version upgrades possible — with sharper edges.","category":"code","date":"January 2, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">P</span>hysical 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.\n\nLogical 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.\n\n## What changed in 2026\n\n- **Cross-version upgrades via logical replication became standard.** The near-zero-downtime major upgrade path drove adoption.\n- **Change data capture pipelines matured.** Streaming database changes into other systems became routine integration.\n- **Slot monitoring became a required practice.** Disk-full incidents from abandoned slots made it a standard alert.\n- **Schema change handling stayed manual.** DDL still does not replicate, and tooling only partially compensates.\n\n## What it enables\n\n| Capability | Physical | Logical |\n| --- | --- | --- |\n| Replicate a subset of tables | No | Yes |\n| Target on a different version | No | Yes |\n| Target accepts its own writes | No | Yes |\n| Different indexes on the target | No | Yes |\n| Replicate into a different system | No | Yes |\n| Efficiency | Higher | Lower |\n| Operational simplicity | Higher | Lower |\n\nThe 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.\n\nThe different-system row is what makes change data capture work — streaming changes into a search index, a warehouse, or an event bus.\n\n## Two things that catch people\n\n**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.\n\nThe 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](/blog/expand-contract-migrations-2026) pattern applied across a replication boundary, and it requires deliberate coordination.\n\n**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.\n\nThis surfaces as replication working fine until the first update on a particular table, which makes it confusing to diagnose.\n\n## The slot that fills your disk\n\nThe most common operational failure with logical replication, and it takes down the *source* database.\n\nA replication slot tracks how far a subscriber has consumed. The source retains write-ahead log segments until every slot has read past them.\n\nIf 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.\n\nThis 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.\n\n**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.\n\n## Common mistakes\n\n- **No slot monitoring.** Source disk fills; a source outage from a target problem.\n- **Forgetting to drop slots for removed subscribers.** The most common cause.\n- **Assuming DDL replicates.** It does not; coordinate schema changes.\n- **Tables without a replica identity.** Updates and deletes fail.\n- **Using logical where physical would do.** More flexibility, more operational surface.\n- **Writing to replicated tables on the target.** Conflicts, unless you designed for them.\n- **Not planning sequence handling.** Sequences do not replicate their state.\n\n## FAQ\n\n**Should I use logical or physical replication?**\nPhysical 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.\n\n**Does it handle large transactions well?**\nA 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.\n\n**Can I replicate bidirectionally?**\nPossible and it introduces conflict resolution, which is a genuinely hard problem. Avoid unless you have a specific requirement and a clear conflict strategy.\n\n**What about sequences?**\nSequence state does not replicate, so a target promoted to primary may reissue identifiers already used. Handle sequences explicitly during a switchover.\n\n## Where to go next\n\nFor the physical alternative and its lag characteristics, read [replication lag](/blog/replication-lag-explained-2026) and [read replicas explained](/blog/read-replicas-explained-2026). For coordinating schema changes across the boundary, [expand and contract migrations](/blog/expand-contract-migrations-2026).","hue":320,"metaTitle":"Logical Replication: Replicating Changes, Not Blocks","metaDescription":"How logical replication streams row-level changes, what it enables that physical replication cannot, and the replication slot trap that fills disks.","keywords":["logical replication","change data capture","selective replication","replication slots","replica identity","cross version upgrade","postgres replication","database operations 2026"],"tldr":["**It replicates row changes, not storage blocks** — so the target need not be identical.","**Schema changes do not replicate** — you apply them on both sides yourself.","**An inactive replication slot retains logs forever** — the classic way to fill a disk.","**Tables need a replica identity** — usually a primary key, or updates and deletes cannot replicate.","**Skip:** logical replication where physical replication would do. It is more flexible and more to operate."],"readTime":"4 min read","wordCount":833},"related":[{"slug":"replication-explained-2026","title":"Replication explained in 2026: how databases stay in sync across nodes","excerpt":"Database replication keeps copies of your data on multiple servers for availability and read scaling. Here is the practical 2026 guide to getting it right.","category":"code","date":"April 7, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":321},{"slug":"synchronous-replication-2026","title":"Synchronous Replication: Paying Latency for Durability","excerpt":"Waiting for a replica to confirm every commit removes the data-loss window on failover. It also puts a network round trip in the path of every single write.","category":"code","date":"January 19, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":302},{"slug":"change-data-capture-explained-2026","title":"Change Data Capture Explained in 2026: How CDC Works","excerpt":"Change data capture streams database changes to other systems the moment they commit, without polling. Here is how log-based CDC works and where it fits in a 2026 data stack.","category":"code","date":"July 31, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":302}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"fireproof-safe-guide-2026","title":"Fireproof Safes: What the Rating Actually Means","excerpt":"A safe rated to protect paper will not protect a hard drive, because the temperature that chars paper destroys electronics long before. The ratings are specific and frequently misread.","category":"guides","date":"January 2, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":165},"older":{"slug":"pipeline-parallelism-explained-2026","title":"Pipeline Parallelism: Splitting a Model Across Machines","excerpt":"Give each machine a contiguous block of layers and pass activations along the chain. It scales across ordinary networks, and it introduces idle time you have to engineer away.","category":"ai","date":"January 2, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":208}}