An application user can see the correct records for that user’s role without seeing the entire population required by a database migration. Before comparing export and destination counts, the project should define which population the transfer is authorized and intended to include.
This distinction matters when a service uses row-level policies to limit visibility. A successful role-scoped query can demonstrate correct application access while answering a different question from whether an export contains every record in the approved migration scope.
Establish the documented export behavior
The PostgreSQL 18 pg_dump documentation describes a default intended to export all table data. It requests row security off and raises an error if the user lacks the necessary bypass privileges. The separate row-security option allows an export of the contents the user can access.
Requesting that setting is not a grant of new privileges or a global removal of the application’s security policies. The selected route and the export identity determine the documented behavior to evaluate.
The buyer should not assume that an application’s export screen, another migration service and this utility all choose the same population. Each method needs to be identified in the transfer plan.
Agree which population belongs in the migration
Consider a hypothetical multi-team service in which each operational role sees its own records. A migration might intentionally move one team’s data. Another project might be authorized to move the complete service population.
A role-scoped export can be appropriate for the first objective while incomplete for the second. Conversely, a complete-table transfer can exceed the intended scope of a narrowly authorized move. More exported rows do not automatically mean a better result.
The acceptance requirement should therefore identify the approved population before selecting a method or interpreting a total. This example does not authorize wider access, export actual records or prescribe bypassing a production policy.
Connect the identity, method and expected records
The proposed checklist separates the decisions that a simple row count cannot explain.
| Review item | Question for the owner | Evidence to retain |
|---|---|---|
| Approved scope | Which records should move? | Defined migration population |
| Export identity | Under whose access does the method run? | Identified operating role |
| Method behavior | Full table or policy-visible subset? | Applicable documented configuration |
| Reconciliation | Does the destination match that scope? | Agreed population-specific checks |
The expected count should come from the same approved population as the transferred records. A count produced through one role should not silently become the total for a different role or a complete-table migration.
Rehearse with distinguishable synthetic populations
A useful controlled pilot includes records belonging to different test populations and identifies which belong in the transfer. Reviewers should observe whether the chosen method includes the intended records and excludes those outside the approved scope.
If the method reports insufficient privileges, retain that result and resolve the operating plan with the responsible owner. It is not evidence that the export succeeded with all rows, nor a reason to represent the failed attempt as a silent partial migration.
The application access test should remain separate. The source role may correctly see only its own records, while the migration needs a different authorized method for its agreed scope. Those observations can both be valid. This article has not changed policies, granted privileges or run an export.
Compare OceanBase on the required destination behavior
OceanBase’s product overview presents a relational platform relevant to modernization. An OceanBase proposal should demonstrate the approved data population and the application’s required destination access behavior for the specific product and deployment.
A general compatibility statement does not establish identical PostgreSQL row-policy interfaces or export options. A proposal retaining PostgreSQL, or using MySQL with an appropriate application access design, should also identify how its transfer and operating controls meet the requirement.
The buyer should assess migration completeness and application visibility as related but distinct outcomes. A destination can contain the intended records while needing its access arrangement checked, just as an application can enforce the intended view while an export covers the wrong population. Neither result should be used as automatic proof of the other.
Accept a population-specific reconciliation
The handover should state the authorized record scope, export identity, actual method and evidence that the destination matches the intended population. It should separately identify the application access checks that support normal service operation.
That makes database replacement easier to evaluate. OceanBase and mainstream alternatives can be compared on preserving both the agreed data scope and the intended application view, with row totals interpreted against a clear population rather than treated as self-explanatory proof of completeness.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.