How OceanBase’s HTAP Architecture Solved Our MySQL Scaling Pain Points

Core Business Architecture Pain Points

In the early stage of our business we built MySQL on Alibaba Cloud ECS and leveraged a self‑built DBaaS platform for fast OLTP development. As data volume exploded, the architecture revealed several critical issues.

Pain Point 1: Expensive Distributed Refactoring

When a single MySQL cluster cannot meet read demand, we resort to sharding and splitting tables, which introduces high refactoring costs and requires extensive coordination between business and DBA teams for each expansion, limiting rapid growth.

Pain Point 2: Inflexible Node Scaling

Our current MySQL sharding solution grew from one cluster to eight shards, causing massive resource waste and persistent data‑balancing challenges.

Pain Point 3: Inadequate Support for Real‑Time Analytics

The existing architecture only satisfies OLTP scenarios; MySQL cannot handle real‑time analytical workloads, hindering business development.

Pain Point 4: Rigid Data‑Storage Strategy

The heavyweight MySQL distributed setup cannot quickly adapt to changing compliance requirements, preventing agile adjustments of storage policies.

HTAP‑Enabled Architecture Upgrade with OceanBase

After evaluating several data products, we selected OceanBase 4.x for its native distributed architecture, HTAP capability, multi‑tenant design, high compression, and rich ecosystem.

1. Native Distributed Architecture – Strong Consistency & Elastic Scaling

OceanBase’s Paxos‑based consistency and full data verification ensure zero data loss; nodes can recover within 8 seconds. We tested scaling from a 1‑1‑1 zone layout to a 2‑2‑2 layout with stable performance.

2. Single Engine Supporting HTAP Mixed Workloads

OceanBase’s row‑column hybrid storage and unified engine deliver OLTP transaction processing while providing millisecond‑level responses for OLAP queries. In a test with millions of rows and 10‑20 concurrent aggregation queries, performance was dozens of times faster than MySQL, with no impact on core TP workloads.

3. Multi‑Tenant & High Compression Reducing Costs

Eight MySQL clusters were consolidated into a single OceanBase cluster with multiple tenants. Resource utilization improved dramatically, and storage cost dropped over 60% (900 GB in MySQL became 170 GB in OceanBase). Each tenant consumes less than one‑fifth of the resources of a comparable MySQL instance.

4. Rich Ecosystem & Tooling

OceanBase offers a suite of management tools (OMS, ODC, OCP) and integrates with over 400 third‑party tools, enabling real‑time migration, synchronized tasks, visual cluster lifecycle management, and full‑link diagnostics.

Since deploying OceanBase, we have achieved more than 60% storage cost reduction, over four‑fold improvement in real‑time analytical performance, and seamless support for both OLTP and OLAP workloads. The platform’s elasticity, strong consistency, and comprehensive ecosystem have also lowered operational and development overhead.

Future Plans

Explore multi‑region disaster‑recovery architectures while maintaining data compliance.

Gradually shift core MySQL traffic to OceanBase, using OMS for downstream data lake synchronization.

Introduce ODC to create an integrated data‑development platform and evaluate OceanBase’s row‑level recycle‑bin for enhanced fault tolerance.