NetEase Games is the gaming division of NetEase, Inc., one of the world's seven largest game companies and a leading developer of online games in China. Since establishing its online games business in 2001, the company has built a portfolio of titles that has repeatedly ranked first in China's overseas publisher revenue rankings since 2018. Its operations serve a global player base across mobile, PC, and console platforms, with infrastructure that has to absorb the long-tail concurrency profile of live-service games — sustained workloads punctuated by launch-day and event-driven traffic spikes.

The Challenge 

The game business platform had grown its MySQL deployment into the classic one-master, multi-slave topology — a primary plus more than ten read replicas absorbing the bulk of business reads. At the platform's current scale, four pain points were compounding on that topology simultaneously.

• High concurrency, low jitter tolerance — at peak the master sustained close to 100,000 QPS, each replica handled tens of thousands more, and aggregate fleet QPS approached one million; the business could not tolerate latency jitter at that concurrency level.
• Per-host storage pressure — individual nodes had accumulated more than 10 TB of data, an uncomfortable footprint for a single-instance OLTP MySQL deployment.
• Replica freshness requirements — read replicas had to track the primary in near real-time, so any slow query that pushed replica lag fed straight into business impact.
• Operational fragility — bursty event traffic could only be relieved by spinning up additional instances, and a failed replica forced a full instance rebuild; at this data volume, expansion, backup, and restore each took hours, a recovery window the business could not absorb.

Why OceanBase

Solving the four pain points required a distributed database that could scale horizontally with stable performance — and absorb heavy archival-driven query load without one business interfering with another. The team set its selection criteria in priority order:

1. Stable performance — query-latency sensitivity demanded near-zero jitter and no slow queries.
2. High concurrency — peak master near 100K QPS, aggregate replica reads approaching 1M.
3. Smooth horizontal scale — per-host storage headroom for continuing data growth.
4. Low replication latency — second-level sync against the upstream MySQL primary.
5. Lower total cost — at this dataset size, operating economics had to improve.

OceanBase matched these end-to-end:

• Financial grade high availability — a three-replica distributed architecture with automatic failover, RPO = 0 and RTO under 8 seconds, hardened at Ant Group's payment scale and across financial-core deployments.
• Transparent elastic scale — online scale-out and scale-in with automatic load rebalancing, transparent to the application.
• Real-time data sync — a month of pre-production stress and live-traffic testing showed near-zero replication delay against the MySQL primary, meeting the freshness bar the legacy replica fleet kept missing.
• Multi-tenant resource isolation — each tenant looks like a MySQL-equivalent instance to the application, with CPU, memory, and IOPS isolated between tenants on the same cluster, so multiple game businesses can share infrastructure without cross-business interference.
• LSM-tree storage compression — encoding and compression at the micro-block level deliver 70%–90% savings against MySQL's B+ tree, with no query-performance degradation since each micro-block now carries more rows.

Two further properties closed the case: full MySQL compatibility removed code-change cost from the move, and HTAP capability opens a path to consolidating future TP+AP workloads onto the same cluster.

The Solution 

NetEase Games deployed OceanBase as a complete-dataset companion to the existing MySQL stack, not a drop-in replacement.

The MySQL primary stays operationally lean: historical data is periodically purged based on business rules to keep its footprint manageable. OceanBase, deployed as a three-replica distributed SQL cluster, receives the full data stream from MySQL via continuous logical replication. The replication link is configured to ignore the primary's purge DML and DDL, so OceanBase retains a complete historical dataset for business queries. Production read traffic that the MySQL replica fleet could no longer absorb migrates progressively onto OceanBase, which carries the load on one distributed SQL database with elastic horizontal scale built in.

Rather than executing a hard cutover, the team began routing a defined share of read traffic to OceanBase while OMS, the OceanBase migration tool, kept the cluster in sync — a pattern that let the new system absorb production load progressively without exposing the application to migration risk.

The Results: A Distributed Data Architecture Sized for the Next Round of Growth

Two outcome layers emerged from the rollout: the headline metrics that justified the project on its own terms, and a set of operational dividends that compounded as the legacy primary shed load.

• Stable latency under 15% of peak read-replica traffic. OceanBase has absorbed approximately 15% of the original MySQL read-replica QPS at steady, low-jitter latency — the proof point that gated further migration.
• 80% reduction in storage cost. Comparing OceanBase against MySQL on a single-copy basis, total storage cost dropped by more than 80%. Archiving upstream MySQL data on top of the migration compressed the remaining footprint by a further 30%+.
• 3× faster backup and recovery. Because the compressed data footprint is materially smaller, replacing a failed node requires far less data to be moved than the equivalent MySQL operation — cutting backup and recovery time to roughly Tone-third of the prior baseline.

Beyond the headline metrics, the migration path itself reduced operational risk: routine OMS replication from MySQL into OceanBase, combined with periodic cleanup of business data on the source side, dropped the systemic risk that had been growing alongside the MySQL dataset. The team also gained a credible elastic path for future concurrency growth — capacity that previously required adding MySQL instances now scales by adjusting cluster resources online.