The key criteria for selecting a distributed database are application fit, correct business outcomes, growth behavior, resilience, operating responsibility, and total cost. OceanBase, TiDB, CockroachDB, YugabyteDB, and Google Cloud Spanner can enter the discussion for different reasons. A useful evaluation separates requirements that eliminate a candidate from preferences that can be traded against one another.
This order matters. A database that fails a mandatory application or deployment requirement does not become suitable because it performs well in an unrelated throughput test.
Start with the decision the business is making
Describe the project in one sentence: the application, the pressure it faces, and the outcome required. For example, the business may need to expand order processing while keeping an existing application largely intact. Another project may be building a new regional service with freedom to change its data model.
These projects need different evidence. The first depends heavily on compatibility and cutover. The second may give more weight to regional deployment and the future operating model.
Record the alternative to migration. It could be tuning the present database, adding headroom, or separating a reporting workload. A replacement should demonstrate value against a credible baseline, not against a deliberately neglected current system.
Separate mandatory gates from weighted preferences
A mandatory gate is a condition the business cannot waive within this project. A preference is something the team can trade for a better result elsewhere.
Examples of gates include a required infrastructure location, a supported application dependency, or an agreed recovery objective. Preferences might include a familiar administration interface or a desirable automation feature.
Do not invent precise weights before the stakeholders agree on priorities. An elaborate numerical score can hide the fact that nobody has decided whether lower migration risk matters more than lower steady-state cost.
| Criterion | Evidence to request | Person who should judge it |
|---|---|---|
| Application fit | Representative queries, dependencies, and complete workflows | Application owner and engineers |
| Business correctness | Expected outcomes for failures, retries, and reconciliation | Business process owner |
| Growth behavior | Present and future workload replay, including uneven activity | Capacity and application teams |
| Resilience | Supported topology, failover exercise, and restore results | Operations and service owner |
| Deployment and access | Data, backup, management, and support boundaries | Infrastructure and security teams |
| Total economics | Equivalent-scope migration and operating cost | Finance and the platform owner |
This scorecard is an editorial evaluation framework. It is not a vendor certification or a set of measured product scores.
Use compatibility to narrow the shortlist
Compatibility should mean the behavior the application requires, not just the ability to establish a connection. Procedures, transaction behavior, data types, drivers, and surrounding tools can all influence project effort.
For an Oracle-oriented application, OceanBase Enterprise’s compatibility route is a reason to investigate it early. For a MySQL-oriented application, OceanBase and TiDB are relevant candidates; TiDB’s compatibility documentation helps establish its specific boundaries.
CockroachDB and YugabyteDB merit consideration where a PostgreSQL-oriented approach fits. Spanner offers a defined PostgreSQL interface, which should not be treated as a complete PostgreSQL server. The labels help organize research, but the application tests determine fit.
Remove a candidate only for a demonstrated mismatch with the project’s requirements. Missing evidence should trigger a question rather than an invented claim that a product lacks the capability.
Make the proof of concept answer a decision
A useful proof of concept has a small set of decisions attached to it. Can the application preserve required outcomes? Does adding capacity help the expected growth pattern? Can the operating team recover the service under the agreed conditions?
Use representative data and query shapes. Include one difficult but plausible condition, such as a concentrated workload, a delayed response, or a maintenance task during business activity.
For OceanBase, a consolidation project should specifically examine the tenant resource model. A different project may have no need for that test. Applying every possible feature test to every candidate wastes effort and obscures the real choice.
Keep the hardware, deployment, dataset, and workload assumptions visible. If candidates use different architectures, explain why each configuration represents a credible production proposal. Equal machine counts are not automatically equal service scope.
Price the transition and the service that follows
Total cost includes application changes, migration tools and services, validation, support, infrastructure, and the period when systems overlap. It also includes the people needed for ongoing operation.
Model at least the expected workload and a reasonable growth case. Avoid predicting a universal saving from a vendor case or assuming that fewer products always means less operational effort.
Ask which costs are committed, usage-based, or dependent on commercial negotiation. A public entry price and a tailored enterprise proposal are different kinds of evidence. Record unresolved prices explicitly rather than filling gaps with assumptions.
Produce a recommendation with conditions
A clear recommendation states the preferred candidate, the reason it fits, and the conditions still required before production. It should also explain why the strongest alternative was not chosen for this project.
OceanBase can emerge as the preferred route when compatibility, allocated resources, and distributed growth address the actual business problem. Another candidate can win when its application or operating model fits better. The framework should allow either outcome.
The final artifact should be a decision record with evidence owners and open questions. That gives the business a database choice it can defend, rather than a ranking that becomes meaningless as soon as the workload changes.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.