How OceanBase Crushed TPC‑C: Inside the Record‑Breaking Distributed Database Benchmark

1. OceanBase’s TPC‑C Test Overview

OceanBase, the distributed relational database developed by Ant Group, secured the #1 position in the TPC‑C benchmark, the authoritative standard for online transaction processing (OLTP) systems. The test evaluates order‑creation and payment workloads under high concurrency.

2. Test Preparation

The team spent over a year preparing for the test, including securing two of the three official TPC‑C auditors and building a fully compliant Remote Terminal Emulator (RTE) alongside the database server (SUT).

3. Test System Architecture

The benchmark requires a Remote Terminal Emulator (RTE) and a DB Server (SUT). OceanBase used OpenResty as the Web Application Server (WAS) and implemented a custom, fully audited RTE. The deployment ran 960 RTE clients on 64 cloud servers, simulating 47,942,400 user terminals.

4. Test Planning

Hardware selection covered both DB nodes and RTE/WAS nodes, using only generic Alibaba Cloud ECS i2.16xlarge instances. Parameter tuning focused on the number of warehouses per node and storage allocation, balancing performance with cost.

5. Performance Testing

The test followed the three TPC‑C phases:

Ramp‑up: 10 minutes of warm‑up.

Steady state: 25 minutes at 60.88 million tpmC with a checkpoint.

Measurement interval: 8 hours of data collection, total runtime > 8.5 hours, with performance variation under 0.5 %.

Large consistency‑checking queries scanned tables with over a trillion rows, and the latest OceanBase 2.2 parallel execution framework handled them efficiently.

6. ACID Tests

OceanBase passed all ACID sub‑tests:

A (Atomicity) : Both distributed and local transactions were exercised.

C (Consistency) : Twelve cases, including complex SQL, were validated.

I (Isolation) : Nine cases of serializable isolation were run in both local‑ and distributed‑two‑phase‑commit modes.

D (Durability) : Using Paxos‑based log replication, the system survived forced power‑off of a node and continued serving without data loss.

7. SQL Optimizations for TPC‑C

Key techniques included stored procedures, Just‑in‑Time compiled code via LLVM, array binding, prepared‑statement caching, and updatable views to reduce client‑server round‑trips.

SELECT i_price,i_name,i_data FROM item WHERE i_id = ?;

UPDATE stock SET s_order_cnt = s_order_cnt + 1, s_ytd = s_ytd + ?,
    s_remote_cnt = s_remote_cnt + ?,
    s_quantity = (CASE WHEN s_quantity < ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?
WHERE s_i_id = ? AND s_w_id = ?
RETURNING s_quantity, s_dist_01, ...;

CREATE VIEW stock_item AS
  SELECT i_price,i_name,i_data,s_i_id,s_w_id,s_order_cnt,s_ytd,s_remote_cnt,
         s_quantity,s_data,s_dist_01
  FROM stock s, item i WHERE s.s_i_id = i.i_id;

UPDATE stock_item SET s_order_cnt = s_order_cnt + 1, s_ytd = s_ytd + ?,
    s_remote_cnt = s_remote_cnt + ?,
    s_quantity = (CASE WHEN s_quantity < ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?
WHERE s_i_id = ? AND s_w_id = ?
RETURNING i_price,i_name,s_quantity,s_dist_01, ...;

The diagram below contrasts the traditional client‑server model with the stored‑procedure approach.

8. Transaction Engine Challenges

OceanBase runs on ordinary ECS nodes with local disks, requiring software‑level fault tolerance. Paxos synchronizes redo logs across three replicas, guaranteeing durability even when a node is powered off. Automatic two‑phase commit handles cross‑warehouse transactions, and a multi‑version concurrency control (MVCC) system provides serializable isolation.

9. Storage Optimizations

OceanBase stores two data replicas and three log replicas (FDL mode). Online compression reduces warehouse size from ~70 MB to ~50 MB. Compaction is carefully throttled and isolated across CPU, memory, disk I/O, and network I/O to keep performance variance below 0.5 % during the 8‑hour run.

10. Future Directions

While the distributed architecture offers low hardware cost and linear scalability, single‑node performance and OLAP capabilities still lag behind traditional databases. Ongoing work focuses on improving per‑node storage throughput and enabling push‑down OLAP queries on compressed data.