Plan sequence state before a PostgreSQL logical-replication handover

Include sequence state and separately managed schema changes in a logical-replication handover.

Source facts

PostgreSQL 17 logical replication copies table data but does not replicate sequence state. Values already stored in serial or identity columns arrive with their rows; the subscriber’s sequence itself is not advanced by that replication. Database schema and DDL changes are also outside logical replication. Before using a subscriber as a writable replacement, the sequence values need updating appropriately, and schema changes need their own coordinated process. A read-only subscriber and a writable successor have different readiness requirements.

Source: PostgreSQL 17 — Logical Replication Restrictions.

Applicability

This applies to PostgreSQL 17 logical replication when a subscriber may become writable. It does not describe physical streaming replication or claim that sequence adjustment alone completes a handover.

DSE recommendation

DSE recommends maintaining a handover checklist for sequence-backed columns and separately managed schema changes. Decide how writes will be stopped while the final source state is reconciled. Have the database owner approve the intended next-value behavior, including any application assumptions about generated identifiers. Keep a clear record of the authoritative data source and the point after which applications may write to the subscriber. Do not use matching row counts as the sole readiness decision.

Verification

Rehearse the planned handover with representative tables, including identity or serial columns. After reconciling state in the test environment, perform inserts and inspect generated identifiers and constraint behavior. Record schema differences and sequence adjustments explicitly before approving any equivalent production transition.

Official reference

PostgreSQL 17 — Logical Replication Restrictions. Reviewed October 15, 2026.