Didi is one of the world’s largest mobility platforms, serving 650 million users across ride-hailing, taxi, hitch, designated-driver, and premium mobility services. Its database estate includes more than 10,000 MySQL clusters, including over 400 single-instance clusters larger than 2 TB. These systems support real-time dispatch, financial transactions, operational services, and company-wide analytics. Since 2024, Didi has run OceanBase in production across five mission-critical workloads: the ride-hailing growth (feature-store) service, mid-platform and designated-driver core archival libraries, EP, and its autonomous-vehicle service — progressively displacing TokuDB and RocksDB.

Challenge

Scale had turned Didi's database stack into a drag on both performance and product velocity. Four pressures converged:

• Latency on 10-billion-row tables. Single-SQL access to the largest tables was drifting into the hundreds of milliseconds and tripping service timeouts, with no clean sharding path for tables that carried transactional dependencies across query dimensions.
• DDL that stopped iteration. Schema changes on tens- to hundreds-of-terabyte archival services took days to weeks, forcing product teams to plan around a database that could not keep up.
• TP and AP on separate rails. Analytics required a downstream big-data pipeline that added operational overhead and pipeline fragility.
• Consistency versus scale. Financial-grade workloads demanded strong consistency, forcing forced-read-primary and turning growth into a chain of resharding events.

An earlier distributed-database evaluation had been rejected after routine scaling and index operations raised latency by roughly 40%, while intermittent jitter under unchanged traffic reached 40–90% — neither of which parameter tuning could resolve. Stability, not benchmark peaks, became the primary selection criterion for the next round.

Solution

Since 2024, Didi has landed OceanBase across five production workloads with distinct load and consistency profiles. The deployment leans on OceanBase's native distributed storage, multi-tenant unit model, and OCP-driven operational stack.

• Cost-efficient archival that scales without resharding. For very large archival services, Didi runs OceanBase on high-capacity storage machines that the prior sharded engine could not use — its large instance made backups and split recovery too slow, and concentrating small instances on a single host multiplied the blast radius. OceanBase's Unit-split model handles node scale-out in minutes and Unit split in hours, and Didi sizes machine capacity against a per-node recovery budget calibrated to MySQL's 3 TB recovery baseline.
• De-risking the migration end to end. In gray migrations, first-touch access to thousands of upstream tables triggered a hard-parse storm that inflated latency more than tenfold. Working with application teams, Didi collapsed those tables into a small number of downstream tables — a rename-suffix change on the application side — restoring predictable response times. Validation was the other bottleneck: full-data checks initially ran for days on multi-terabyte tables. Upgrading OMS and enabling its large-field filtering feature — which excludes non-critical wide columns from validation — brought that into the hours range, while OMS Diagnose tunes concurrency across full and incremental sync.
• One table serving every query dimension. Didi's ride-hailing growth feature store carries single tables at 10-billion-row scale, wide-schema, with mixed range-query patterns across drivers, orders, and passengers. Partitioning by dimension combined with global indexes lets those query patterns hit one table with consistent low latency — no sharded copies to keep in sync.

The biggest highlight of OceanBase's partition tables is the ability to partition by different dimensions — we can serve order queries, driver queries, and passenger queries from the same table with consistently low latency.

Wu Qipeng

Head of Distributed Storage Operations, Didi

• Stability under traffic spikes and retry storms. The feature store enforces a 200ms circuit-breaker; historically, transient issues produced retry storms that compounded pressure on the database. Didi replaced fixed 200ms retries with a stepped 200 / 400 / 800ms cadence, set throttling thresholds against actual SQL-audit concurrency at the 90th percentile, and consolidated SQL templates from thousands to under 100 so that template-level throttling stays effective. Didi is adopting OceanBase 4.3.5 BP3's library- and table-level throttling as a second protection layer.
• Preserving the downstream ecosystem. Didi's Canal → MQ/Kafka pipelines feed real-time data to multiple business lines — for several of them, a hard dependency. OceanBase's Binlog Server converts transaction logs into MySQL-compatible binlog format, so Canal connects without modification and the entire downstream investment carries over. When Binlog Server was still single-node, Didi bridged the gap with a DIY high-availability pattern — multiple OBProxy instances feeding multiple Binlog Servers, with Canal failing over on file-position-plus-timestamp recovery — since retired by Binlog Server 4.x native HA, now in production.

Results

Two years into production, the outcomes span cost, performance, and delivery speed — measured across five workloads, not a pilot:

• 20% storage cost cut on 100+ TB archival. OceanBase's compression combined with large-disk deployment reduced storage cost by roughly 20% versus the prior TokuDB sharded architecture, on an archival library peaking at 8,000 QPS.
• ~30ms daily latency on a feature store peaking at 25K QPS. The ride-hailing growth service now holds daily response latency at roughly 30ms on 10-billion-row-scale tables — well inside its 80ms SLA and clear of the 200ms circuit-breaker threshold.
• Low-teens-millisecond p99 on archival after table consolidation. Once thousands of upstream tables were consolidated into a small downstream footprint, archival p99 settled in the low teens of milliseconds on the migrated workload.
• Data validation cut from days to hours. Field-filtered OMS validation moved multi-terabyte checks into an hourly window, giving Didi's migration cadence back.
• Elastic scaling in minutes, not maintenance windows. Node scale-out completes in minutes and Unit splits in hours, with latency flat during scaling aside from a brief blip at node switchover — a durable contrast with the ~40% rises and 40–90% jitter seen in the previously evaluated distributed database.

Looking Ahead

With OceanBase now anchoring five production workloads, Didi's next moves target the largest MySQL clusters and financial-grade active-active scenarios. The DBA team is working with OceanBase on canary upgrade with rollback and more balanced Binlog Server HA failover — capabilities they see as prerequisites for absorbing the top of the scale curve.