Amap (formerly AutoNavi), part of Alibaba Group, is China's leading digital map and mobility platform. It serves more than 150 million daily active users on a typical day, climbing past 360 million during peak national-holiday travel. Beyond navigation, Amap has become an everyday platform for travel, dining, and local services — a scale of usage that turns ordinary features into extreme data problems. Two of its most demanding services — Footprint and Cloud Sync — had outgrown the manually sharded MySQL architecture beneath them, straining against hard limits on cost, stability, and scale. Amap migrated both to OceanBase, which now serves as their system of record.

Challenge

The Footprint service gives each user a personal travel timeline — a record of their own trips and the places they've been that they can review, manage, and share. As the feature gained adoption at Amap's scale, it grew to more than 700 billion records across 360TB of storage, with peak read/write concurrency averaging over 270,000 requests per second — all under a strict 10-millisecond response target.

For years, Footprint ran on a manually sharded MySQL cluster. The pattern had scaled the early business, but at this volume its limits had become structural rather than incidental:

• Stability. Index and schema changes on large sharded tables produced user-visible latency jitter, turning routine maintenance into a release-planning exercise.
• Engineering velocity. With sharding, routing, and rebalancing logic living in the application, every model change had to be coordinated across dozens of shards — slowing feature delivery to the pace of the database, not the product.
• Cost. Storage overhead grew faster than the business, and the sharded design offered no structural path to reverse it.

Cloud Sync — which keeps a user's data consistent across their own phones and in-car systems — carried a parallel set of demands: 500 billion records spread across three regional units, real-time cross-region consistency, and sub-10ms responses for a service where any lag is immediately felt by the user.

Why OceanBase

Amap's team scoped the selection around three requirements, each tied directly to a business outcome:

After testing and head-to-head comparison, three OceanBase capabilities proved decisive:

• High-ratio storage compression — the dominant cost lever at this dataset size.
• Strong MySQL compatibility — minimal application change, which is what makes an online migration of a live, hot service tractable.
• Native multi-active architecture — cell-based deployment shaped by the business, not constrained by the database.

"Without OceanBase's native multi-active capability, the data-sync logic would have had to live in the application layer. That would have significantly increased system complexity and substantially raised both development and maintenance cost."

Li Yan,

Head of Online Services Engineering, Amap

Solution

Footprint: an online migration at 700-billion-row scale

Replacing the database beneath a hot service this large is the hard part, and Amap completed it with zero incidents and no user-perceptible impact. Three practices made that possible:

• Single-point cutover control. Every traffic ramp and rollback decision was routed through one enforcement point in the service chain, keeping the cutover strongly synchronized end to end. Without it, a partial cutover sends a write to OceanBase while a dependent read still hits MySQL — exactly the kind of skew that corrupts a live migration.
• Three-layer validation.Data, SQL, and business-logic checks ran in parallel, and the migration was treated as verified only when all three passed — not any one alone.
• High-throughput sync via OMS.OceanBase Migration Service sustained roughly 10 million rows per second during full-data sync, compressing the migration window enough to make an online cutover viable at this scale.

Footprint now runs on a single OceanBase cluster with native horizontal partitioning. The application no longer manages shards — it sees one logical table that OceanBase distributes and rebalances internally. OceanBase's LSM-tree engine compacts baseline data with columnar encoding and LZ4 compression, and because that baseline is read-mostly, the compression adds no query-latency penalty. Online DDL removes the schema-change jitter entirely: index changes that once required release planning now run without observable impact.

Cloud Sync: three-site active-active with multi-write

Cloud Sync's defining trait is that users move between regions and write from whichever of their devices is nearest. The topology is built around that reality:

• Three write-capable cells in Shanghai, Zhangbei, and Shenzhen — spanning eastern, northern, and southern China — with user-level routing directing each user to their home cell and correcting on the fly when they travel.
• Financial-grade durability per cell, using OceanBase's three-site, five-replica Paxos deployment for lossless disaster recovery.
• Six-link bidirectional replication — three cell-pairs, two directions each — keeping every user's state coherent across regions. Cross-cell consistency is owned by the database via OMS, not reimplemented in the application.

Because each cell stores and serves data within its own region and cross-region replication is configured explicitly, the same pattern maps directly onto data-residency requirements: an operator can keep data in the regions it chooses while still delivering active-active availability across them.

Results

Both services have run clean through the country's two heaviest annual traffic peaks — its largest online shopping festival and the national-holiday travel rush.

• Storage cost down 55.2%. A 2.23:1 compression ratio at the 360TB baseline cuts the largest line item in the deployment. Because Footprint grows with daily active users, this is the saving that compounds rather than flattens over time.
• Reads 25.7% faster. Average Footprint response time fell from 5.95ms to 4.42ms. Against a 10ms SLA, that roughly doubles the headroom between average latency and the budget — the margin that keeps p99 inside the SLA when a downstream component degrades.
• Cloud Sync at 220,000 QPS/TPS with average response under 10ms, and cross-region failover now measured in minutes. Failover became a property of the database rather than a coordinated application rollout, which is what makes one-button regional escape credible during a real incident.
• Application-layer sharding code removed across both services. Developers now use OceanBase like a single MySQL instance, while partitioning, routing, and rebalancing happen beneath the surface.

"Simpler for our developers, lower cost at scale, and dependable multi-active high availability. This wasn't just a database swap — it was an architecture evolution that leaves us room to grow."

Li Yan,

Head of Online Services Engineering, Amap