Combining application shards requires a plan for record identity as well as data movement. Two shards can each contain a valid customer or order number that is not unique across the whole estate. OceanBase and other distributed engines may simplify future distribution, while Vitess offers a route around retained MySQL. Neither project should assume that old identifiers become globally unambiguous merely because the target platform can store the data.
The business needs to preserve the meaning of a record and the references that point to it.
Find out what an identifier actually identifies
A displayed customer number, a database key, and an external integration reference may be different things. Record which identifier is used for each purpose.
Determine whether the original application interprets a number together with a shard, customer group, or region. Removing that context during consolidation can change the meaning even if the number itself remains unchanged.
Inspect references outside the database too. Reports, invoices, exported files, support tools, and partner systems may retain identifiers that cannot be changed casually.
This turns identity from a technical column question into a business relationship inventory.
Check the different collision and reference cases
Use a small set of cases whose expected meanings are clear.
| Case | Question to answer | Evidence needed |
|---|---|---|
| Same number in different shards | Are these different entities or duplicate representations of one entity? | Original ownership and business identity |
| Related records | How does an order identify the correct customer after consolidation? | Preserved relationships and representative journeys |
| External references | Which systems continue using the old identifier? | An integration inventory and supported transition plan |
| Historical records | Can an earlier event still be interpreted correctly? | Source context or a documented mapping |
| New records after migration | How is identity assigned and communicated? | The intended application behavior and tests |
The table defines requirements. It does not prescribe an identifier algorithm or assume a database can infer the intended business identity.
Keep merging and renumbering as separate decisions
Combining storage does not necessarily mean combining two business entities. A repeated identifier may require retained source context rather than a customer merge.
If the project changes identifiers, define the mapping and every affected reference. Establish who can approve the business consequence and how old references remain interpretable.
If it preserves identifiers, demonstrate how ambiguity is avoided in the consolidated application. The answer may involve the application’s existing domain boundaries or an approved target design.
Avoid a migration that silently fixes a collision by changing a value while leaving invoices, integrations, or historical reports pointing to the old meaning.
Evaluate OceanBase with the identity model included
OceanBase’s Enterprise product information provides a route for evaluating a different database engine. Its value in reducing application-owned distribution should be assessed together with the retained business boundaries.
Use a pilot containing records from more than one original shard, including a deliberate repeated identifier and related records. Confirm that the application retrieves and updates the intended entity.
Do not assume every original shard should become a database tenant. A shard can represent geography, capacity, customer ownership, or a historical implementation choice. The target mapping should preserve the business requirement that actually matters.
For Vitess, the clustering and sharding route retains MySQL, but the chosen routing and identity design still needs application validation. A platform can manage distribution without deciding the semantics of the business’s old identifiers.
Reconcile identity before transferring write authority
Compare entity counts, representative relationships, and the application outputs that depend on identity. A successful row transfer cannot establish that every order belongs to the intended customer.
Include updates and deletes after the initial copy. Verify that the target applies each event to the correct record under the selected transition method.
Test the external references that cannot change at the same time. The plan should show how a partner or support tool reaches the right business record during and after migration.
Preserve mappings and source context needed for investigation. A future operator should not need the original migration engineer to explain an old record’s identity.
Make the result part of the application contract
Document the identity rules used by the consolidated service, how new records are created, and how old references are resolved. Assign an owner to changes in that contract.
OceanBase can be a strong candidate when distributed data management fits the application and the identity model is validated. Vitess or another route may fit a different transition boundary.
Check the customer-facing record as well as internal references. A historical invoice or support case may contain the old identifier even after the application adopts a new internal key. The business needs a reliable way to connect the two without treating an unrelated customer’s matching number as the same entity.
The successful outcome is not simply fewer shards. It is a service that continues to identify the correct customer, order, or account across old data, new work, and connected systems. That is the foundation that makes simpler distribution useful to the business.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.