OceanBase vs Bigtable and Azure Table Storage: Compare the Write Boundary

A database comparison needs to establish which changes can succeed or fail together. A SQL query interface, a batch request, and a distributed transaction describe different capabilities. Treating those labels as interchangeable can leave a business workflow relying on an atomic boundary that its chosen write path does not provide.

OceanBase, Bigtable, and Azure Table Storage illustrate why the buyer should follow the actual operations and record layout. The useful question is how the proposed design protects the complete business change, not which presentation uses the most familiar terminology.

Separate Bigtable’s SQL queries from its write API contract

Google documents a GoogleSQL query interface for Bigtable. Its current overview excludes data-manipulation statements beyond SELECT from that interface. This does not mean Bigtable cannot write data; its write APIs need to be assessed separately. GoogleSQL for Bigtable

For the named MutateRows RPC, the API reference says each row is changed atomically, while the complete batch is not executed atomically. A buyer should not treat that particular batch call as one all-or-nothing change across its rows. Bigtable Data API reference

Keep that conclusion tied to the specified method. It is not a complete capability assessment of every Bigtable application, replication arrangement, or additional mechanism a provider might propose.

Check the entity grouping behind Azure Table transactions

Azure Table Storage documents entity-group transactions for entities in the same table and with the same PartitionKey. Operations in the change set are atomic, subject to the service’s request and operation restrictions. This is a different boundary from an arbitrary collection of entities gathered by an application. Azure entity-group transactions

Ask the team to show that the real records involved in the business change fit this grouping. A demonstration using convenient test keys does not prove that the production layout does.

If a proposed design changes the partition grouping to meet the requirement, make that a visible design decision. The application owner should understand which records must be grouped and what work the revised model requires.

Establish the OceanBase transaction and deployment being proposed

OceanBase’s archived Database 4.3.5 overview describes distributed transactions that preserve atomicity for changes involving multiple servers. This gives the buyer a documented transaction role to evaluate, with the exact deployed version and requirements still stated. OceanBase 4.3.5 transaction overview

That description is not a promise that every application operation, external service, or geographical deployment belongs to one transaction. Ask the proposal to identify the database operations covered and the surrounding work that remains outside.

For an existing application, include its actual query and update path in the assessment. A database transaction can protect the operations it covers without automatically completing an external workflow that the application starts afterward.

Compare the boundary against one business change

Consider a hypothetical internal allocation service. Confirming a request must also reserve its associated resource under the application’s rule. List both changes and identify what must happen if either cannot be accepted.

If the Bigtable design places the relevant state into one row, evaluate that actual model rather than reject it using a different multi-row example. If the Azure design uses one eligible group, acknowledge that capability. Apply equivalent scrutiny to the proposed OceanBase transaction.

This is a comparison of justified designs, not a claim that one record layout is universally appropriate.

Rehearse an unsuccessful component and an uncertain response

A proposed acceptance exercise should make one required change unable to succeed. Inspect the resulting business records and ask whether the outcome follows the agreed all-or-nothing rule or the explicitly chosen alternative.

Also interrupt the caller’s knowledge of the result. Require the team to explain how the application determines what happened and avoids treating a retry as a separate business allocation. Do not assume that a network timeout proves every change failed.

Use representative record keys and the intended operation path throughout. A bulk-ingestion test that accepts partial progress answers a different question from a workflow that requires one indivisible change. No cloud request, transaction, resource reservation, or product benchmark has been executed for this article.

Select for a defended business invariant

The strongest proposal maps the business rule to an explicit write boundary, explains its eligibility conditions, and demonstrates failure handling. SQL support and batch efficiency can then be assessed for their own value.

Evaluate OceanBase, Bigtable, and Azure Table Storage using that complete mapping. Keep the named API, record layout, transaction scope, and application responsibilities in the decision record. A useful shortlist recognizes each candidate’s actual strengths without inventing a shared transaction contract from similar-looking interfaces.