TiDB vs OceanBase vs PolarDB: Architecture Differences and Ideal Use Cases

Core positioning

TiDB

– distributed SQL + HTAP platform built on a decoupled compute‑storage layer. OceanBase – native distributed OLTP kernel with strong consistency, high availability and multi‑tenant isolation. PolarDB – cloud‑native compute‑storage‑separated system; PolarDB‑X adds sharding and distributed transaction capability.

Architectural breakdown

TiDB

Components: TiDB Server – stateless SQL layer (parse, optimize, generate distributed plans). PD – scheduler for timestamps, Region placement and load‑balancing. TiKV – row‑store transaction engine. TiFlash – column‑store analytical engine.

Scaling is independent for each layer:

Add TiDB servers to increase SQL concurrency.

Add TiKV nodes to increase KV storage capacity.

Add TiFlash nodes to increase analytical throughput.

OceanBase

Each OBServer embeds SQL, storage and transaction engines. Data hierarchy: Zone → Partition/Tablet → Log Stream. OBProxy provides routing. Tenant is the basic unit for resource isolation.

PolarDB

Compute nodes are stateless and access a shared distributed storage. A single writer handles writes; multiple read‑only nodes share the same storage. PolarDB‑X implements sharding, distributed transaction and horizontal write scaling.

Deep technical comparison

Data organization

TiDB stores data as Key‑Value pairs in TiKV, split into Region units that drive scheduling, replication and load‑balancing.

OceanBase partitions tables into Tablet units bound to Log Stream for replication and log management.

PolarDB uses a shared‑storage model with a single‑writer; PolarDB‑X adds sharding and distributed execution.

Consistency and transaction model

TiDB uses Multi‑Raft, MVCC and Percolator‑style 2‑phase commit (2PC). Transaction flow:

SQL generates an execution plan.

Keys are mapped to multiple Regions.

Pre‑write ( prewrite) is issued. PD assigns a global timestamp.

Commit ( commit) is executed.

Each Region replicates via Raft.

OceanBase uses Multi‑Paxos replication, a global time service and MVCC to achieve atomic cross‑partition commits.

PolarDB provides strong consistency for the single‑writer path via shared‑storage replication; distributed capabilities are provided by PolarDB‑X.

HTAP and analytical capability

TiDB leverages TiFlash for real‑time HTAP without ETL, suitable for minute‑level dashboards.

OceanBase can run analytical queries but its primary focus remains core OLTP.

PolarDB delivers good analytical performance on read‑heavy workloads but does not integrate row‑column storage like TiDB.

High availability and disaster recovery

TiDB relies on Raft for leader election and Region‑level failover.

OceanBase uses multi‑zone Paxos with automatic failover.

PolarDB uses shared‑storage replication and fast primary‑read replica switchover.

Engineering perspective

High‑concurrency writes

TiDB – watch for hotspot Regions; use AUTO_RANDOM, hash‑based keys, and limit large transactions.

OceanBase – align partition key with business access patterns; design tenant‑level routing.

PolarDB – single‑writer limits horizontal write scaling; consider PolarDB‑X when write throughput becomes a bottleneck.

Scalability

TiDB – linear scaling of SQL, KV storage and column‑store independently.

OceanBase – scaling tied to tenant resource allocation and partition rebalancing.

PolarDB – rapid addition of compute nodes and read replicas; storage scaling is simple.

Operability

TiDB – clear component model, mature open‑source ecosystem, suited for teams with platform engineering capability.

OceanBase – powerful but requires experienced DBAs and governance processes.

PolarDB – “database‑as‑a‑service” model reduces operational complexity, ideal for teams preferring cloud‑managed solutions.

Production case studies

E‑commerce order platform (TiDB)

Requirements: tens of thousands of orders per second and real‑time dashboards.

Architecture:

Transactional data stored in TiKV.

Analytical queries run on TiFlash replicas.

MySQL‑compatible migration is straightforward.

Sample DDL and real‑time query:

CREATE TABLE orders (
    order_id BIGINT PRIMARY KEY /* AUTO_RANDOM can be used in TiDB */,
    user_id BIGINT NOT NULL,
    merchant_id BIGINT NOT NULL,
    status TINYINT NOT NULL,
    amount DECIMAL(18,2) NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    KEY idx_user_created (user_id, created_at),
    KEY idx_merchant_created (merchant_id, created_at)
);

ALTER TABLE orders SET TIFLASH REPLICA 2;

SELECT merchant_id,
       COUNT(*) AS order_cnt,
       SUM(amount) AS gmv
FROM   orders
WHERE  created_at >= NOW() - INTERVAL 10 MINUTE
  AND  status IN (1,2,3)
GROUP BY merchant_id
ORDER BY gmv DESC
LIMIT 100;

Bank core accounting (OceanBase)

Requirements: strong consistency, multi‑zone disaster recovery, multi‑tenant isolation.

Key design points:

Partition tables by institution or account number.

Co‑locate related tables in the same partition to minimise cross‑partition transactions.

Separate batch processing and online transaction workloads into different tenants or resource pools.

Sample transfer transaction:

BEGIN;
UPDATE account SET balance = balance - 1000
WHERE account_id = 'A1001' AND balance >= 1000;

UPDATE account SET balance = balance + 1000
WHERE account_id = 'B2001';

INSERT INTO account_ledger (tx_id, debit_account, credit_account, amount, tx_time)
VALUES ('TX202604180001', 'A1001', 'B2001', 1000, NOW());

COMMIT;

Cloud SaaS platform (PolarDB)

Requirements: read‑heavy workloads, traffic spikes, minimal ops.

Architecture:

Single writer handles writes.

Multiple read‑only nodes serve analytical and reporting queries.

Shared storage enables fast scaling of compute nodes.

When write scaling becomes a bottleneck, evaluate PolarDB‑X or application‑level sharding.

Production‑grade integration code

Spring Boot datasource configuration (MySQL‑compatible endpoint)

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://db-proxy.prod:3306/order_center?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true
    username: app_user
    password: ${DB_PASSWORD}
    hikari:
      maximum-pool-size: 60
      minimum-idle: 10
      connection-timeout: 3000
      validation-timeout: 1000
      idle-timeout: 600000
      max-lifetime: 1800000
      transaction-isolation: TRANSACTION_READ_COMMITTED

Idempotent order service (Java)

@Service
public class OrderService {
    private final JdbcTemplate jdbcTemplate;
    private final TransactionTemplate transactionTemplate;

    public OrderService(JdbcTemplate jdbcTemplate, TransactionTemplate transactionTemplate) {
        this.jdbcTemplate = jdbcTemplate;
        this.transactionTemplate = transactionTemplate;
    }

    public Long createOrder(String requestId, Long userId, Long merchantId, BigDecimal amount) {
        return transactionTemplate.execute(status -> {
            Long existingOrderId = jdbcTemplate.query(
                "SELECT order_id FROM order_idempotent WHERE request_id = ?",
                rs -> rs.next() ? rs.getLong(1) : null,
                requestId);
            if (existingOrderId != null) {
                return existingOrderId;
            }
            Long orderId = jdbcTemplate.queryForObject("SELECT NEXTVAL(order_seq)", Long.class);
            int inserted = jdbcTemplate.update(
                """
                INSERT INTO orders(order_id, user_id, merchant_id, status, amount, created_at, updated_at)
                VALUES (?, ?, ?, ?, ?, NOW(), NOW())
                """,
                orderId, userId, merchantId, 0, amount);
            if (inserted != 1) {
                throw new IllegalStateException("insert order failed");
            }
            jdbcTemplate.update(
                """
                INSERT INTO order_idempotent(request_id, order_id, created_at)
                VALUES (?, ?, NOW())
                """,
                requestId, orderId);
            return orderId;
        });
    }
}

Read‑write routing (Spring AOP)

public enum DataSourceRoute { WRITE, READ }

@Aspect
@Component
public class ReadWriteRouteAspect {
    @Before("@annotation(ReadOnlyQuery)")
    public void routeRead() { DataSourceContextHolder.set(DataSourceRoute.READ); }

    @Before("@annotation(WriteCommand)")
    public void routeWrite() { DataSourceContextHolder.set(DataSourceRoute.WRITE); }

    @After("@annotation(ReadOnlyQuery) || @annotation(WriteCommand)")
    public void clear() { DataSourceContextHolder.clear(); }
}

Selection framework – ten‑question checklist

Is the core contradiction write scaling, read scaling or TP+AP integration?

Is cross‑zone strong consistency required?

Does the workload depend heavily on MySQL or need Oracle compatibility?

Do transactions frequently span accounts, merchants, tenants or large partitions?

Are there obvious hotspot keys, tenants or time windows?

Will growth in the next 2‑3 years be driven by data volume, concurrency or query complexity?

Does the team prefer open‑source self‑managed solutions or cloud‑managed services?

Is strong multi‑tenant isolation and resource quota needed?

Is minute‑level real‑time analytics required without ETL?

Can the project accept deep coupling with a specific cloud provider?

Answers converge to: TiDB for TP+AP with MySQL heritage. OceanBase for financial‑grade OLTP, strong consistency and multi‑tenant governance. PolarDB for cloud‑native elasticity, read‑write separation and low‑ops overhead.

Common misconceptions

Benchmarks are not a substitute for workload‑specific evaluation.

MySQL compatibility does not guarantee zero migration effort.

Database choice must consider organizational capabilities, not just technical specs.

Final takeaway

TiDB

solves distributed SQL + HTAP integration; OceanBase solves core OLTP + strong consistency; PolarDB solves cloud‑native elasticity and operational efficiency. The appropriate choice depends on the specific business contradictions a system must resolve.