02/10 edition: PostgreSQL — replication does not decide who writes
Schema, sequences and final reconciliation belong in the handover contract; return changes character once the destination accepts new operations.
- Author
- Redação Velqory
- Recovered day
- 2026-10-02
- Actual publication
- 2026-10-05
- Editorial review and verification
- 05/10/2026 · Europe/Lisbon
- Nature
- Retrospective analysis published on 5 October; it does not represent original publication on that date. Original, untested Velqory operational proposals; no drill or internal experience is claimed.
- Review
- Revalidate documentation and criteria before any intervention and whenever version or configuration changes.
In brief
Schema, sequences and final reconciliation belong in the handover contract; return changes character once the destination accepts new operations.
- Prepare schema and sequences as separate handover tracks.
- Reconcile final operations after suspending write admission.
- Block return after new writes until their reconciliation is demonstrated.
Who can write during the handover?
This 2 October reference edition is retrospective analysis published on 5 October. It announces no migration, new release or Velqory test. It addresses database administrators and application owners considering a service handover supported by PostgreSQL logical replication.
The question is not merely whether rows reached the destination. It is who may accept the next write and which conditions allow returning that authority to the origin. We propose a handover contract with explicit states: preparation, writes suspended, reconciliation, destination authorized and possible return. The proposal is untested and requires adaptation to actual versions.
The data contract includes schema
PostgreSQL 18 documentation states that schema and DDL commands are not replicated. When incoming data does not fit the subscriber's schema, replication errors until the schema is updated. This is a documented limitation, not a failure observed for this article.
We propose that the application team declare the expected schema for every in-scope table and suspend concurrent changes during the agreed window. The administrator compares definitions and actual usage; row counts are insufficient. A column introduced at the origin without preparing the destination should block handover, not trigger improvisation after opening traffic.
A copied row does not update the sequence
The same chapter distinguishes serial or identity column values, copied with rows, from sequence state, which is not replicated. For a switchover to the subscriber, the documentation requires updating sequences.
In a hypothetical scenario, orders are present but the sequence for the next insertion is behind. We propose inventorying sequences and identifier reservations, selecting a safe rule for each application and verifying the next write in an authorized drill. We offer no universal recipe based only on the largest visible identifier. Cached values, reservations and internal conventions should enter the owner's decision.
Worker observation is not handover authorization
Monitoring documentation identifies pg_stat_subscription as the view exposing subscription-worker information. Worker numbers depend on state, including initial synchronization. Activity alone is not the acceptance criterion we propose.
Ask the team for an evidence plan covering lag and application of the last accepted operations. In Velqory's design, admission of new writes is suspended, closure of in-flight operations is checked and an identified final set is reconciled. An isolated apparently zero-lag indicator does not replace that proof. Define in advance what happens if reconciliation exceeds the window.
The destination needs a write owner
The conflicts chapter warns that replicated changes can update data modified locally on the subscriber and that constraint violations can stop replication. Do not treat local destination writes as harmless validation.
We propose one authorized write owner at each plan state. Include applications, scheduled tasks, integrations and administrative access in the review. Before authorization, the destination should receive only operations anticipated by the design. An unexpected write should interrupt handover and trigger reconciliation. Record who decided, which connections were reviewed and the final operations set.
Write the return boundary before changing over
The matrix is an original, untested proposal. After the destination accepts new operations, do not authorize return merely because the origin still starts. Require a decision about those operations, sequences and external effects; without demonstrated reconciliation, return remains blocked.
Preserve the origin under the approved plan and define who may abandon handover before opening. A promise of automatic rollback is not evidence. This analysis offers an auditable decision boundary, not a guarantee of brief downtime or no loss.
Handover and return contract
Velqory's proposed conditions; not measured results.
| State | Owner | Evidence | Pass / fail |
|---|---|---|---|
| Preparation | Application and DBA | Schema and sequence inventory | Pass with compatible scope; fail with unresolved definition. |
| Write closure | Operations | Suspended admission and final operations | Pass with identified final set; fail with unknown writer. |
| Destination authorization | DBA and service owner | Reconciliation and identifier rule | Pass with accepted proof; fail with gap or conflict. |
| Return after new writes | Service owner | Disposition of new operations and external effects | Pass with proven reconciliation; fail without data plan. |
Sources consulted
Consulted on the stated update date.
Opens in a new window.Participate
Share the analysis. Add context.
Distribute the article through your channel or leave an observation connected to the topic.
Comments
Loading the conversation.