Choosing Between OceanBase and TiDB: Architecture, Performance, and Trade‑offs

Background

In recent years distributed databases have become popular in the financial sector, not because centralized databases cannot handle core banking workloads, but because many banks prioritize high availability. Consequently, domestic centralized databases are adding Oracle‑RAC‑like components to address this gap.

OceanBase (Sharding‑Integrated Architecture)

OceanBase follows a compute‑storage‑integrated (SHARDING) model. Each Observer is an independent service that includes SQL, transaction, and storage engines and holds a subset of data partitions. Clients can connect to any Observer, which generates distributed execution plans and dispatches operators to other Observers.

The cluster is managed by a RootService with a single primary and multiple backups. Data is replicated using a Paxos‑based election algorithm, providing high availability and allowing read‑only or weakly consistent reads from replicas.

However, SHARDING introduces a read amplification problem: queries lacking a SHARDING KEY cannot prune partitions and must be executed on all Observers holding the table, increasing latency. Additionally, creating tables without specifying partitioning limits horizontal scaling, and cross‑Observer joins incur network overhead. OceanBase mitigates join costs with TABLE GROUP, co‑locating related tables on the same Observer.

TiDB (Compute‑Storage Separation Architecture)

TiDB adopts a fully separated architecture: the TiDB SQL layer runs on compute nodes, while storage resides in TiKV (and optional TiFlash). This eliminates the SHARDING read‑amplification issue because data is not tied to a specific compute node.

Nevertheless, TiDB faces challenges due to the lack of a global buffer. Each compute node has only local cache, so data must travel over the network to TiKV/TiFlash, which can increase latency for latency‑sensitive OLTP workloads. Optimizations such as operator push‑down, smart scan, and local read buffers for immutable data help mitigate this.

Performance Trade‑offs

OceanBase’s integrated design can offer lower latency for simple, small‑transaction workloads because data resides locally within each Observer, avoiding network hops. TiDB’s separation introduces stable but higher network latency per operation, yet it scales better for large write‑intensive transactions where push‑down of operators to storage nodes reduces overall execution time.

Complex queries benefit from TiDB’s finer‑grained distributed execution plans that are pushed directly to TiKV/TiFlash, whereas OceanBase must route operators through multiple Observers, adding an extra layer of communication.

Choosing the Right Database

When evaluating OceanBase versus TiDB, run representative complex SQL workloads on both systems. For applications with modest complexity and high latency sensitivity, OceanBase may be advantageous. For large‑scale write‑heavy or analytical workloads, TiDB’s compute‑storage separation and push‑down capabilities often provide better performance.

Beyond architecture, consider factors such as resource management, multi‑tenant support, HTAP features, vendor support, and ecosystem integration when making a final decision.

Illustrations