Xiaomi Group is one of the world’s largest consumer electronics and internet-services companies, spanning smartphones, AIoT devices, and a growing portfolio of internet services across a global footprint. Behind the consumer brand, its database estate runs on a deliberately mixed foundation: self-built IDCs, public-cloud capacity, and isolated compliance-bound zones for overseas markets, carrying some of the most demanding workloads in consumer internet. Flash sales and live-streaming campaigns push the database layer harder than almost anything else in the company’s stack. To meet those pressures without paying for idle standby capacity or being locked into any one cloud, Xiaomi re-platformed its most demanding workloads onto OceanBase.

The Mandate: What the Next Stack Had to Solve

As Xiaomi’s business scaled and flash sales pushed the database layer harder, the next-generation stack had to solve several things at once.

• Sharding overhead was compounding on every capacity change. Large workloads ran on manually sharded MySQL behind proxy layers. Keeping individual nodes lightweight pushed sharding and routing logic up into applications, so every resize carried operational overhead the team paid in engineering hours. As data volumes climbed from millions of rows toward billions, the model grew harder to reason about. Speed on a small cluster couldn't rescue it: fast databases capped at a few nodes hit a wall the moment the business keeps growing.
• Two-center DR wasted an entire standby cluster. In regions with only two data centers, the classic answer was a primary in one center and an idle backup cluster in the other — hardware paid for, zero work done. Three-replica Paxos needed a third site the team didn't always have, so there was no clean way to get scale, disaster recovery, and no wasted hardware all at once.
• AP queries forced extra infrastructure onto the MySQL stack. The common workaround for analytics on MySQL was to hang extra AP-only nodes off the proxy: added boxes and added ops, without solving the underlying "one engine per workload type" limit.
• Single-cloud dependency was both an outage risk and a lock-in trap. Xiaomi's estate spans self-built IDCs, public cloud, and many isolated and compliance-bound zones. Any single cloud will eventually see an incident over a five- or ten-year horizon, and being tied to one provider's infrastructure would make later workload moves expensive. That two-sided exposure was something the next stack couldn't inherit.
• Compliance-bound zones ruled out most database options up front. Global services couldn't operate at all in some markets without meeting local data-compliance rules, so any database that couldn't slot cleanly into isolated, compliance-bound zones was disqualified before performance numbers entered the conversation.

Any replacement had to solve all of these at once. The DBA team knew this was a tall order: stability, scale, performance, cost, deployment flexibility, and freedom from lock-in. Conceding on any one of them meant re-facing one of the items above at the next capacity inflection.

The Solution: One Unified Distributed Database

Xiaomi chose OceanBase for two decisive reasons:

• An unified architecture the collapses the stack with:
  • Single-node-to-distributed integration,
  • Storage-and-compute seperation,
  • A unified TP/AP engine,
  • Multi-tenancy for multiple workloads
• The operational flexibility to fit a hybrid-cloud, multi-zone reality without wasting resources.

Deployment Architecture

For standard workloads, Xiaomi runs OceanBase across three centers with three full-featured replicas — one leader and two followers — under a multi-tenant model, with applications talking to OBServer through ODP proxy. Where only two centers are available, the team pairs full replicas with an arbitration replica rather than standing up a wasteful backup cluster. Physical-log-based replication ties clusters together for primary-standby scenarios.

Consolidation: One Engine for Many Workloads

Consolidation happens at three levels: the engine underneath, the cluster on top, and the workload mix each cluster carries.

• Sharded MySQL displacement. Workloads previously spread across manually sharded MySQL fleets aggregated onto OceanBase's distributed engine, collapsing application-level sharding and routing logic into a single system. MySQL wire-protocol compatibility kept application changes to a minimum.
• Multi-tenant cluster sharing. Many businesses share clusters instead of dedicating one per business — which would be wasteful at Xiaomi's scale — with tenant-level resource isolation as the hard boundary that keeps one workload's spikes from destabilizing its neighbors.
• HTAP without a second stack. The older pattern of bolting AP query nodes onto a MySQL primary through a proxy is being retired in favor of serving analytics on the same OceanBase platform that carries the TP load — analytical needs met in place, not by adding boxes.

Scale: Distributed by Default

Scale rests on two things: a consistency guarantee that holds across a distributed footprint, and placement flexibility that lets a single engine serve very different workload shapes.

• Paxos-based synchronous replication across replicas provides the consistency guarantee.
• Partition-leader placement tuning. Concentrate leaders on a single zone to shorten response time for latency-sensitive TP workloads (fewer cross-node hops); distribute leaders across zones to exploit multi-node resources for AP-heavier workloads. Same engine adapts to both patterns — a placement decision, not a re-platforming.

Efficiency: No Idle Standby, Compressed Storage

Two features let Xiaomi meet its DR requirements without paying for hardware that did no work, and compression pays down the storage bill on top.

• Arbitration replicas — the 4.x successor to the earlier log-type replica — let a two-center deployment reach an odd-numbered quorum by adding a participant that carries no full data copy. Because consensus doesn't require the data, the arbitration replica is largely insensitive to distance: centers as far apart as Beijing and Guangzhou remain viable.
• Primary-standby tenants operate at the tenant level rather than the cluster level: two clusters back each other up, each acting as primary for its own tenants while hosting the other's standby. Neither cluster sits idle purely as insurance — a direct answer to the requirement that every deployed resource carry real load.
• LSM-tree compression. Compression shrinks the on-disk footprint directly, with the exact ratio depending on workload and the baseline database being compared against.

The Results

The move to OceanBase shifted cost and reliability in the right directions together: overall database costs came down materially after the migration.

• Sub-8-second RTO with zero data loss. Xiaomi observes automatic-recovery RTO under 8 seconds — a bar the team considers stricter than most vendors will guarantee — with RPO = 0, built on Paxos-based synchronous replication.
• 3–5× storage compression. LSM-tree compression typically delivers 3–5× reduction in on-disk footprint; combined with instance consolidation, this is a primary driver of the TCO reduction Xiaomi has observed post-migration.
• P99 latency in the MySQL range. Transactional performance on OceanBase approaches that of the prior sharded-MySQL-plus-proxy stack, so consolidation did not come at the expense of the latency-sensitive paths flash-sale traffic depends on.
• No idle standby cluster. Arbitration replicas in two-center regions and mutual primary-standby tenants across clusters keep every deployed resource carrying real load.
• Multi-tenant resource isolation lets many businesses share clusters without contending for each other's capacity, retiring the operational tax of sharded MySQL along the way.
• Product maturity and ecosystem. Upstream and downstream tooling plus overall usability lower the operational cost Xiaomi's team would otherwise absorb.

Looking Ahead

Xiaomi's next phase is already underway. Internally, the team is investing in customizable monitoring and metrics, running regular failure drills, and pushing elastic scale-up/scale-down controls out to business teams who best understand their own resource needs. On the engine side, columnar storage and vectorization are the focus of active research and POCs, driven in large part by growing investment in AI and large-model workloads, where vector search is essential.