PostgreSQL 16: Logical Replication That’s Now Practical

Actualizado: 2026-05-03

PostgreSQL 16, released in September 2023, didn’t ship a headline feature so much as something far more valuable to anyone running databases in production: it closed, one by one, the four or five cracks that had turned logical replication into an exercise in patience. Today, for cross-version migrations, geo-distributed architectures with local reads, or reasonable CDC pipelines, the correct answer nearly always begins with the logical replication built into the database itself.

Key takeaways

• Parallel apply on the subscriber: 2-5x throughput improvement on write-heavy loads vs PG15.
• Physical standbys can expose logical slots of their own, offloading the primary.
• Bidirectional replication adds the scaffolding but does not resolve conflicts automatically: primary-key partitioning discipline is required.
• Conflicts stop the subscription and emit the exact LSN: ALTER SUBSCRIPTION ... SKIP or DISABLE/ENABLE to resolve.
• Logical replication does not replicate DDL or sequences: explicit plan required for every migration.

Logical vs physical: the usual misunderstanding

Physical replication ships raw WAL to a byte-identical replica — the foundation of hot standbys and failover. Logical replication decodes that WAL as high-level operations tied to a publication. That decoding carries a CPU cost the physical path doesn’t pay, but in exchange enables replication between different versions, to targets with different schema, or to consumers that aren’t PostgreSQL. They are complementary tools.

The cracks that closed

Parallel apply: up to PG15 subscriber apply was strictly sequential. PG16 introduces parallel workers controlled by max_parallel_apply_workers_per_subscription. Typical improvement for write-heavy loads: 2-5x throughput.

Slots on standbys: from PG16, a physical standby can expose its own logical slots and feed downstream consumers, enabling cleaner fan-out architectures.

Bidirectional replication: not automatic multi-master. What is added is the scaffolding to build it without external extensions, provided the application respects primary-key partitions that prevent simultaneous writes to the same row on two nodes.

Publications, subscriptions, and conflict resolution

CREATE PUBLICATION mypub FOR TABLE users, orders;

CREATE SUBSCRIPTION mysub
  CONNECTION 'host=primary port=5432 dbname=mydb user=replicator password=secret'
  PUBLICATION mypub
  WITH (streaming = parallel);

Conflicts don’t resolve automatically: PG16 stops the subscription, marks it as errored, and emits the exact LSN in the log. You manually decide: fix the source, skip with ALTER SUBSCRIPTION ... SKIP (lsn = ...), or disable and re-enable after repair.

What remains out of scope

Honest picture of what PG16 doesn’t do: no DDL replication (apply manually on both sides in order), no automatic sequence sync (advance with setval after cutover), large objects remain out of scope.

Operations and migrations

Logical replication shines in two contexts:

Minimum-downtime migration: subscribe from source PG14/15 to a freshly provisioned PG16, let it converge, pause the application for a few seconds of final catch-up, switch the connection string, decommission the old one. Minutes of window versus hours of a classic pg_dump.

CDC into a data warehouse: Debezium subscribes to the logical slot and pushes changes to Kafka. Key metrics: pg_replication_slot_retained_wal_bytes and the delta between confirmed_flush_lsn and pg_current_wal_lsn(). An orphaned slot can fill the primary’s disk in hours.

PostgreSQL 16 doesn’t turn logical replication into a magic switch; it removes the technical excuses that for years kept it relegated to marginal cases.