An operator can reduce the number of separately maintained databases while still running several business systems. The important design decision is how those systems map to the proposed shared foundation. Fewer instances do not, by themselves, explain who owns a workload or how competing needs are resolved.
The historical Jiangsu Mobile example makes that mapping a useful starting point for an OceanBase evaluation. Its lesson is to identify business-system boundaries and operating responsibilities before treating pooled resources as an automatic simplification of the whole application estate.
Read the original mapping as a historical design
OceanBase’s 2023 case collection describes a Jiangsu Mobile arrangement with several production clusters and different business systems mapped to different tenants. The account discusses resource pooling alongside application adaptation, testing, migration, and operational changes.
This is a historical supplier description. It does not establish the operator’s present topology, demonstrate that every tenant was a separate company, or prove that a multi-year plan mentioned in the account was subsequently completed. The design pattern is the relevant evidence here, rather than an assumed current inventory.
That pattern asks a concrete question of a new project: what business responsibility does each proposed tenant represent?
Choose the unit that the team needs to manage
An application system, a business function, and a customer organization are different possible boundaries. A project should explain which one it is using and why. A tenant should not be assigned a business meaning merely because the product provides a place to create one.
For a hypothetical telecom estate, customer management and internal compensation may have different owners, activity patterns, and change processes. The evaluation can examine whether they should share an operating foundation while retaining those distinct responsibilities.
The example is a planning question, not a reconstruction of Jiangsu Mobile’s application inventory. Its purpose is to make the buyer’s chosen management unit explicit before resource settings and cluster sizes are discussed.
Make the shared responsibilities as visible as the separation
Separate tenants can help organize a consolidated arrangement, but the project should still identify what remains shared. Platform maintenance, infrastructure capacity, and the people handling a wider incident may cross several application boundaries.
Ask who can request more resources and who decides when requests compete. Also ask how an application owner learns about a platform change that may affect its operating plan. These responsibilities should appear in the proposal rather than emerge only after applications move.
Resource organization should not be turned into a promise that workloads can never influence one another. The chosen deployment needs an explanation of its actual controls and shared dependencies.
Build a business-to-platform register
The following framework can make the consolidation design reviewable without requiring every reader to understand the database’s internal scheduling mechanisms.
| Register entry | Question to answer | Responsible perspective |
|---|---|---|
| Business system | What outcome does this workload support? | Application owner |
| Proposed tenant | Why is this the chosen management boundary? | Application and platform teams |
| Shared resources | Which needs compete within the arrangement? | Platform operator |
| Changes and exceptions | Who approves resource changes and handles unresolved impact? | Named decision owners |
Use the register during a representative demand change. For example, one application may need extra capacity while another is running an important scheduled task. Ask how that request would be assessed and communicated, rather than assuming the tenant map resolves the decision automatically.
Evaluate OceanBase for the intended mapping
OceanBase’s Enterprise description provides a platform route to investigate for enterprise consolidation. The historical Jiangsu account supports examining tenant-based organization, but the buyer should request evidence for the resource controls and operating behavior of its selected version and deployment.
Compare that arrangement with retaining separate Oracle or MySQL databases, using a supported managed service, or another realistic consolidation proposal. Separate databases may preserve a familiar ownership boundary, while a shared platform may reduce some repeated operating work. Neither outcome should be presumed from the engine name alone.
Include the work of managing the proposed mapping over time. Ask how a new application is added, how an existing owner changes its needs, and how the team identifies the scope of a platform incident. A design is more useful when it remains understandable after the initial migration.
Accept an operating map that survives growth
The result should identify each business system, its proposed management boundary, the resources it shares, and the decisions that remain coordinated. The register should have an owner who can keep it current.
That is the transferable lesson from the historical tenant-mapping example. OceanBase becomes a stronger candidate when consolidation reduces repeated work while leaving business responsibility and shared-platform decisions clear to the teams that will operate it.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.