A replicated table can contain the expected records while the destination still needs preparation to create new ones. For an application that uses sequence-generated identifiers, migration acceptance should include the first new write after cutover as well as the records copied beforehand.
PostgreSQL logical replication illustrates this distinction. The buyer should establish whether the destination is only serving reads or will become a writer, because those roles require different evidence about future identifier allocation.
Read the documented sequence distinction
The PostgreSQL 18 logical replication restrictions distinguish replicated values in sequence-backed serial or identity columns from the sequence’s own state. The table values are replicated, but sequence state is not.
The documentation notes that this is typically not a problem for a read-only subscriber. It separately calls for sequence preparation when the subscriber will take over through switchover or failover.
This describes the documented replication mechanism, not every migration product or database-copy procedure. A separate tool may handle additional state, which needs its own confirmation rather than being assumed from row replication alone.
Identify which application action follows the switch
Consider a hypothetical service with existing records whose identifiers arrived through logical replication. After cutover, the application creates a new record using a destination sequence. That allocation is new work; it is not simply a read of an identifier already present in the copied table.
If the destination allocator is not prepared for its new role, successful reconciliation of existing rows does not establish that this new action will work correctly. The test should connect the copied identifier population with the intended future allocation behavior.
The example does not claim that every switch produces a duplicate identifier. It identifies a condition to assess for the actual sequence-backed application and proposed transfer method.
Separate copied data from future allocation evidence
The suggested matrix scopes the migration test without prescribing sequence values or commands.
| Review item | Question for the project | Evidence to request |
|---|---|---|
| Existing records | Did the intended identifiers arrive? | Agreed data reconciliation |
| Allocation mechanism | How will new identifiers be produced? | Identified destination design |
| New writer readiness | Has the relevant state been prepared? | Supported cutover procedure |
| Application action | Can a new record be accepted correctly? | Representative post-switch test |
The application owner should inventory the relevant allocation mechanisms rather than assume every identifier uses a sequence. The preparation needed for one column should not be generalized to UUIDs, externally assigned values or unrelated business numbering rules.
Rehearse creating a new record
A useful synthetic pilot first reconciles the transferred records, then exercises an agreed new-record workflow through the intended destination writer. Reviewers should inspect the generated identifier and the resulting application behavior under the proposed cutover procedure.
A representative case should include a destination with copied identifiers already present, rather than testing allocation only against an empty table.
The plan should also identify how writes are coordinated during the transition. Preparing an allocator without considering other active writers is not a complete cutover method. The responsible team needs a supported procedure for its topology and application, rather than a universal instruction to choose a counter from a table maximum.
These checks are separate from claiming that copied data is corrupt or that logical replication failed to transmit the existing identifiers. The documented distinction is precisely that those values can be present while future allocation state needs attention. This article has not changed a sequence, redirected writes or performed a failover.
Compare OceanBase against the actual migration route
OceanBase’s product overview presents a relational modernization option. A proposal should identify how the application’s existing identifiers and future allocation requirements map to its supported product and migration method.
It should not assume PostgreSQL logical-replication procedures apply unchanged to OceanBase. A proposal retaining PostgreSQL, or moving to MySQL with an appropriate identifier design, should likewise demonstrate the specific handoff between transferred records and new writes.
The buyer can accept different allocation implementations when they preserve the agreed application contract. The comparison should include preparation and testing effort, rather than treat equal row counts as proof that the destination is already ready to own every future write.
Accept the first new write as a separate result
The handover should identify the relevant identifier mechanisms, the state transferred or prepared and the application checks performed after the destination becomes writable. It should preserve the existing-row reconciliation as a separate evidence item.
That gives database replacement a practical acceptance boundary. OceanBase and mainstream alternatives can be evaluated on continuing the application correctly, with copied identifiers and future identifier allocation treated as related responsibilities rather than interchangeable proof.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.