OceanBase: How Does It Achieve Extreme Cost Reduction Across Hardware, Storage, and Operations?

This article is excerpted from the e-book “A Study of OceanBase Community Edition Use Cases in Pan-Internet Scenarios”. Click the link to access the full version.

Introduction

From the moment an enterprise starts running, data flows continuously into its storage systems. According to a report from International Data Corporation (IDC), the world will generate 180ZB of data per day in 2025. Faced with ever-growing data processing demands, some storage systems run into problems such as difficult capacity expansion, degraded performance, and rising costs. As a result, more and more enterprises are looking for database solutions that can simultaneously deliver low cost, high efficiency, and high scalability.

As a fully self-developed database, OceanBase can help enterprises save at least 60% on storage costs while also lowering hardware and operations costs. What are the core technologies behind this?

1. One System for the Full Business Lifecycle, Saving Resource Costs to the Extreme

In the traditional database selection process (see Figure 1), a single-node, small-spec MySQL instance is enough to support the business at first. But as the business grows, MySQL gradually fails to meet performance and storage requirements amid data growth. At this point, upgrading the system to high-spec Oracle becomes the choice for many enterprises. When even high-spec single-node Oracle can no longer handle the data volume, they consider RAC shared storage, or even switch the database type for core business, such as to Db2. As the “foundation” and “heart” of a business, a data system must, when being replaced, not only minimize the impact on the business but also account for the replacement cost. A smooth, scalable system therefore greatly reduces both cost and risk. So, is there a single system that can meet a customer’s data management needs across different business scales?

Figure 1 The traditional database selection process

OceanBase 4.x’s standalone-distributed integrated architecture can meet the needs of different business stages. It combines the scalability of a distributed database with the functionality and single-node performance of a centralized database. Through dynamic log streams, it delivers high single-node performance when the system is static, while smoothly and rapidly scaling out by dynamically adjusting log streams. For the storage engine, by making resource overhead small and lightweight, a single engine supports different deployment forms and supports smooth growth from small data volumes to massive scale.

So, for small businesses with small data volumes, a single small-spec OceanBase instance is enough. As the business data grows slowly, the simplest vertical scaling—upgrading the tenant configuration to a higher spec—is all that’s needed. When the business requires disaster recovery or load balancing, OceanBase can easily switch to three replicas; each replica’s data storage still maintains a high compression ratio, reducing the cost increase brought by multiple replicas. For large businesses, demand can be met by scaling out horizontally within the cluster. This is the significance and value of OceanBase’s standalone-distributed integration.

In addition, OceanBase 4.x is more lightweight, smaller-footprint, and more scalable in resource management, making it easier for enterprises to use resources more fully and reasonably, and to save on resource costs.

2. Support for a Million Partitions per Node, with Small-Footprint, On-Demand Metadata Loading to Improve Resource Efficiency

OceanBase innovatively introduced the concept of the log stream to reduce the network and CPU overhead under massive numbers of data partitions. The multiple replicas of each data partition form a Paxos member group to guarantee the consistency of the data’s replicas. To reduce the consensus protocol overhead under many partitions or small specs, the partition logs of the same member group are aggregated together—the so-called single log stream. Only one log stream is needed to handle synchronization or elections, achieving disaster recovery and Paxos high availability for a group of partition replicas.

For memory under massive data volumes, OceanBase designed on-demand loading of metadata, intelligently distinguishing hot and cold partitions and the necessary metadata, greatly reducing memory usage.

As shown in Figure 2, under a log stream there are many Tablets—data shards, which can be understood as a partition of a user table. The Tablet is the most fundamental unit for distributed system load balancing, disaster recovery, and so on. The number of Tablets is exponentially larger than the number of Log Streams. The reason is that the availability-zone topology within a cluster is limited and small in number, whereas the number of partitions is adjusted according to business needs and may reach tens of thousands.

Figure 2 OceanBase partition architecture

In OceanBase 4.x, metadata under partitions is loaded on demand.

• Metadata refers to certain basic attributes of partition replicas, used to support data CRUD operations, LSM-Tree changes, load balancing, disaster recovery, and other standalone and distributed functions. In OceanBase 4.x, metadata is loaded dynamically according to the request load, loading only the data blocks relevant to the query range. So no matter how much the data scale expands, the memory consumed by access to a limited set of hot data does not expand along with it, which further lowers the memory-cost requirements when choosing machine models for historical archives.
• On-demand loading means keeping the metadata of hot partitions in memory while not loading cold partitions—those accessed infrequently—or their metadata. Through hot-cold separation, memory efficiency is maximized. The resident memory under 1 million partitions can be reduced to 200MB. On small-spec machines, this supports more partitions. In scenarios such as historical archives partitioned by time, this makes it possible to store older historical partition data without upgrading the machine spec.

3. More Flexible Disk I/O Isolation Strategies for Safer, Fuller Resource Utilization

OceanBase provides a complete syntax for configuring the maximum or minimum IOPS and weight for each tenant. This lets users flexibly allocate the I/O resources used by tenants, further balancing the disk performance requirements between traffic peaks and troughs, and reducing costs.

As shown in Figure 3, tenant 4 (blue line, IOPS can be capped) requires that maximum IOPS not exceed 5,000, which prevents excessive concurrent traffic from affecting other tenants. Tenants 1 (red line) and 2 (green line) themselves have relatively high IOPS, with their cap configured at 100,000; the weight ratio can control the relationship between high-traffic tenants—for example, always maintaining a 2:1 ratio. What happens to the cluster if tenant 3 (yellow line) newly joins it? Because tenant 4 has a cap, it is unaffected. Tenant 3’s IOPS can be borrowed from tenants 1 and 2, whose weights decrease proportionally. This achieves isolation between tenants.

Figure 3 Configuring tenant IOPS

Besides isolation between tenants, there is also isolation within a tenant. Why do intra-tenant isolation?

Consider two scenarios: First, in a scenario that must serve both TP and AP business traffic, you want to prevent latency-sensitive TP requests from being disrupted and affecting the stability of normal business traffic. Second, in a scenario where foreground and background traffic are isolated, if background resource isolation isn’t done well, it will affect foreground query requests, producing user-perceivable jitter.

Intra-tenant isolation makes it possible to use resources safely and effectively in mixed-workload scenarios. For example, in Figure 4, A, B, C, and D can be different workloads. B’s Min Percent is set to 97%, meaning that although B has the smallest IOPS, you want to guarantee that its minimum IOPS doesn’t drop too low (blue line). A and C have weights of 50:25, and you can see from the figure that they maintain a 2:1 ratio, ensuring that different workloads get their corresponding IOPS.

Figure 4 Isolation capabilities across different workloads within a tenant

4. Compaction Optimization to Reduce Space Amplification and Disk Overhead

As a factor that puts heavy demands on system resources, Compaction has always been one of the most worthwhile core technology hotspots to study and explore deeply in LSM-Tree-based systems. When solving the problems of read amplification, write amplification, and space amplification, different vendors adopt different optimization strategies. Mastery of Compaction technology determines whether more background compute resources can be saved for users and redirected to foreground business requests, achieving a better cost-performance ratio.

After more than a decade of self-developed exploration, OceanBase has innovatively proposed many effective optimization methods and engineering practices for improving Compaction’s compute performance and reducing resource costs such as disk space. For example, it adopts the well-known Tiered & Leveled Policy in the industry, and on top of that designs different types of Compaction based on factors like transaction characteristics, data characteristics, and resource dependencies.

As shown in Figure 5, the entire LSM-Tree’s persistent SSTable has only three levels, differing from the multi-level optimization of RocksDB, Cassandra, and some other systems. Although the levels are few, each level of SSTable has its own design purpose.

• The L0 level aims to release memory as quickly as possible; its data-processing logic must be low-cost and fast.
• The L1 level eliminates read amplification as much as possible, because there may be overlap between data—including spatial data redundancy and temporal redundancy across multiple versions—and disk overhead must also be considered.
• The L2 level must not only thoroughly solve the space amplification problem but also handle more complex functions with transactional and distributed characteristics, such as data verification, reclamation, and compression.

Figure 5 The LSM-Tree persistent SSTable architecture

Based on in-depth analysis of both data processing and system resources, OceanBase designed multiple types of Compaction (mini, minor, medium, major). According to the real-time state of system resources and combined with statistical sampling information, it automatically invokes the appropriate Compaction to dynamically balance and relieve resource bottlenecks and improve system stability. Specifically:

• Mini Compaction is responsible for generating L0-level SSTables, using an efficient dense format on disk that maximizes IOPS while minimizing CPU consumption.
• Minor Compaction is responsible for generating the L1 level, merging multiple L0 and L1 SSTables. Its function is to reorganize multi-version data on the same primary key to improve query performance. It automatically detects the overlapping range of incremental data and reuses data blocks at the macro-block level, reducing space amplification. In the future, it will also support data encoding and compression to further reduce disk overhead.
• Major Compaction produces the L2-level baseline data and is the main contributor to cost reduction. In addition to further reclaiming old versions of data in the incremental data, and using advanced compression techniques in the on-disk format according to the user’s table attributes to reduce storage cost, it also reorganizes and compresses the data holes caused by scattered inserts, better supporting different types of data-update models. Notably, Major also handles data verification across replicas, ensuring data storage is secure and reliable.

As for Medium Compaction, one of its roles is to solve the famous queuing-table problem in LSM-Tree architectures. For example, a user inserts 6 rows of data and then deletes those same 6 rows. Logically, the table is empty. But the number of physical rows actually scanned in a query is still 12. As another example, in a scenario with interleaved updates and inserts, you might get an aggregate count of 2 rows but an actual scan cost of 7 rows. These phenomena come down to a huge difference between physical row count and logical row count, causing query performance to fall short of expectations.

In older versions of OceanBase, users had to explicitly specify the buffer-table attribute when creating a table, hinting to the storage engine to detect buffer tables with many rows and quickly trigger a special Compaction action to reclaim some rows. Starting from OceanBase 4.1, the storage engine intelligently collects statistics on the data each time it generates an SSTable. For each SSTable, a set of vectors represents the update characteristics of this group of data. When characteristics matching a queuing table are detected, the system automatically initiates a Medium Compaction to eliminate redundant data. This process is transparent to the user, requiring no awareness of business characteristics before creating the table, and no forced DDL after the system goes live. This lowers the barrier to using OceanBase and improves stability after business traffic switchover.

5. Encoding and Compression for Extreme Storage Cost Reduction

In addition to reducing overall costs in terms of resource utilization, disk usage, and memory usage, storage cost reduction is also critical. Its core technology lies in the storage engine—especially in massive-data historical-archive scenarios, where the better the storage engine, the more substantial the cost-reduction benefits.

Put plainly, the OceanBase storage engine has architectural advantages for cost reduction that traditional databases lack. Generally, traditional databases based on B+ Tree use in-place updates, and the underlying blocks are fixed-length, so after storage compression there are write-amplification fragmentation problems to solve, which also somewhat affect query performance. OceanBase uses an LSM-Tree storage architecture, which provides more possibilities for database compression. First, it eliminates the random-write disk bottleneck and storage-space fragmentation problems of traditional B+ Tree, delivering higher write performance compared with the traditional approach of updating data blocks in real time. Second, it decouples data updates (inserts, deletes, modifications) from the compression action—there is no compression in the data-update path, so the impact on performance is smaller. In addition, during batch flushes to disk, the database can adaptively adjust the amount of data in a data block, and during compression of consecutive data blocks, it collects and uses prior knowledge such as compression ratios to better compress the next block.

For TP scenarios, the OceanBase storage engine uses a hybrid row-column storage mode (see Figure 6). Unlike row storage mode, the data within a micro-block is no longer laid out row by row but is first organized together by column. During SSTable generation by Compaction, the encoding and compression of a micro-block proceed in two steps. The first step uses the data characteristics of adjacent rows in a given column to choose a suitable algorithm for encoding; the compression ratio after this first layer of encoding often reaches 50%. The second step applies a general-purpose compression to the encoded micro-block, ultimately achieving an extreme compression ratio averaging 30%.

Figure 6 OceanBase storage engine on-disk format

When choosing an encoding algorithm, the OceanBase storage engine automatically analyzes characteristics such as data type, value range, and NDV, and refers to the encoding and compression history of adjacent micro-blocks; it is an adaptive heuristic algorithm. For example, for small-range strings such as license plates, it supports Bit-packing and HEX encoding, which effectively reduce the bit width of storage and achieve encoding compression. For columns with high repetition rates such as gender and zodiac sign, it uses dictionary encoding and RLE encoding to deduplicate single-column data. For strings or columns with similar value ranges, it uses delta encoding. When there is correlation or similar prefixes between columns—such as the barcodes among major product categories—it uses inter-column encoding to reduce redundancy across multiple columns.

For AP scenarios, OceanBase 4.3 implemented support for columnar storage. Under columnar storage, each column’s data is stored as an independent SSTable, and all the columns’ SSTables combine into a virtual SSTable that serves as the user’s columnar baseline data. The core characteristics of the columnar format include columnar encoding algorithms, skip index, and query pushdown. Among these, columnar encoding is responsible for cost reduction; skip index and query pushdown are used to accelerate large-range, highly selective scan performance in AP scenarios, responsible for efficiency gains.

Under the columnar encoding format (see Figure 7), each column of user data is stored on a per-stream basis, and micro-block-level general-purpose compression is removed. Data encoding or compression is done on a per-stream basis, because for integer data, after efficient encoding, applying general-purpose compression yields little benefit; removing general-purpose compression saves CPU. For string data, its metadata and data are stored separately, and all string-stream data is merged together for encoding, which saves on the number of encoding operations while also improving the overall compression ratio.

Figure 7 OceanBase columnar encoding format

6. A Data Storage Architecture That Helps Enterprises Save on Hardware, Storage, and Operations Costs

After many years of fully self-developed exploration, OceanBase has optimized resource overhead and cost to the extreme at every stage from data inflow to outflow, forming a unified, efficient, and scalable data storage architecture.

• In data organization, metadata at each level is loaded on demand, so the system’s memory resources serve more frequently accessed hot data, further reducing the dependence on single-node specs and improving the benefits in small-spec scenarios.
• In the data-write path, multi-level, multi-type compaction strategies ensure efficient write performance while remaining smooth and jitter-free. They automatically compress data holes and produce high-compression-ratio baseline data, reducing storage costs.
• In data queries, all formats support aggregation and filter pushdown, SIMD vectorization, and skip index, improving large-query and AP performance.
• In resource management, the isolation of CPU, memory, I/O, and other resources between tenants is progressively improving, allowing a single cluster to serve multiple business systems and lowering the overall system cost.

Through the technical capabilities of the data storage architecture above, OceanBase helps users achieve cost savings across hardware, storage, and operations.

(1) Sichuan Huadi’s Data Warehouse Construction: 60% Hardware Cost Savings

The “Qijiale Smart Medical and Elderly Care Big Data Public Service Platform” developed by Sichuan Huadi integrates medical, elderly-care, and other resources to provide healthy elderly-care services for seniors. This real-time data computing platform needs to process around 20TB of medical data, and the original Hadoop system had problems such as complex components and difficult operations. By adopting OceanBase, it achieved huge benefits.

First, in terms of data architecture, it went from deploying a Hadoop environment on 10 machines—using more than 20 different open-source components such as ETL, HDFS, Hive, and Spark SQL to handle data import/export, data cleansing, and AP analysis—to running AP analysis directly on a cluster of 3 OceanBase nodes. This improved the original AP analysis performance while reducing servers from 10 Hadoop servers to 4 OceanBase servers, saving 60% on hardware costs. At the same time, it freed the team from the sprawling Hadoop components; using a single OceanBase system to handle HTAP scenario requirements simplified operational complexity.

Second, testing confirmed that OceanBase with three replicas occupies only about 1/3 to 1/4 of Oracle’s storage space: clusters of Oracle and OceanBase were each deployed on 5 machines of the same spec, and a data file of 500 million rows totaling 372 GB was used for an import/export test. After importing the same data into both Oracle and OceanBase, it occupied 220 GB of storage in Oracle, while importing into OceanBase with three-replica storage took only 78GB.

(2) 58.com’s Database Upgrade: 80% Machine Cost Savings

As a comprehensive life-services platform, 58.com covers many businesses including used cars, real estate, recruitment, local services, and finance, and different scenarios have different database requirements, so it needed a database product that could support complex and diverse business scenarios.

58.com first migrated the online data-statistics database used by its DBAs to OceanBase 4.2.1, building a 6-node cluster configured with 64 cores / 512G / NVMe SSD, and unified the original 20+ node TiDB/MySQL clusters onto a single OceanBase cluster, with different businesses’ statistics split by tenant. This not only saved storage space (about 50%) thanks to OceanBase’s high compression ratio but also reduced the node count from 20+ to 6, cutting machine costs by about 80%.

During the go-live process, 58.com used OMS to migrate a 2.1-billion-row table from MySQL to OceanBase. After migration, disk usage peaked at 259GB, and after full compaction the data was about 157GB. In other words, a 1.5TB large single-replica table in MySQL became 155GB across two replicas in OceanBase; viewed per replica, it’s only about 80GB. Going from 1.5TB to 80GB, the overall compression ratio reached 95%.

(3) Energy Monster’s Historical Archive Migration to OceanBase: 71% Storage Cost Reduction

As the first publicly listed power-bank-sharing company, Energy Monster has over 360 million registered users and 1.9 million daily orders, and its business grew so fast that its architecture kept adding components. The hybrid cloud architecture it used at the time was complex, with microservices coexisting alongside multiple data components (MySQL, Elasticsearch, etc.), facing many problems such as high operations costs, high storage costs, and poor scalability.

Energy Monster’s order business is primarily about power banks, characterized by low per-order value and high order volume. The figure below shows the databases used by the order business in MySQL. It mainly included a high-concurrency, real-time database supporting user ordering, an Elasticsearch cluster meeting the need for multi-field joint queries in the backend, and a historical archive using MySQL sharding. After migrating to OceanBase, storage went from the original 9.62TB×2 (9.62TB for a single MySQL instance, multiplied by 2 to account for primary-standby high-availability deployment) to 5.6TB (total storage across three replicas), a 71% reduction in storage costs. 64 MySQL databases were merged into a single cluster, reducing the burden of maintaining sharding, with no capacity bottleneck in the short term, dramatically lowering storage costs and simplifying operations.

(4) Trip.com’s Dual-Business Database Upgrade: 60% Hardware Cost Reduction, 85% Storage Cost Reduction

The rapid growth of Trip.com’s financial business caused the single-table data volume of its business forms to surge sharply to 30 billion KV pairs in 2023, with a daily update peak of up to 50 billion. Faced with such massive data, the original storage architecture struggled with capacity expansion, had poor write performance, could not meet the need for fast data writes, and could not guarantee query stability—seriously affecting the real-time accuracy of the financial business and constraining further business expansion.

After going live with OceanBase, in terms of performance it achieved a write speed of 60 million writes per minute, capable of writing 86.4 billion records per day—far exceeding business needs. The 2-hour completion rate of high-priority tasks rose dramatically from the original 60% to nearly 100%. In terms of cost reduction, total storage space decreased by 72% and hardware costs decreased by nearly 60%. In terms of application architecture, since there was no need to handle complex sharding logic, the application architecture was greatly simplified, and both the number of application machines and CPU cores were reduced by 50%, effectively improving the overall operating efficiency of the system and laying a solid technical foundation for the continued development of Trip.com’s financial business.

Trip.com’s historical archive initially used SQL Server and later migrated to MySQL, but as the business grew, problems such as complex scaling, high storage costs, and time-consuming maintenance gradually emerged. To reduce pressure on the production environment, Trip.com archived cold data to a historical archive, but the MyRocks initially adopted couldn’t meet the surging data demands due to difficult scaling. Subsequently, a 475G table in Trip.com’s MySQL historical archive took only 55G after migration to OceanBase—on average, only 1/8 of the original storage resources—reducing storage costs by about 85%.

(5) Dmall’s New-Retail Transformation: 80% Cost Savings

As a pioneer in the retail digitalization field, Dmall is not only a top domestic provider of comprehensive digitalization solutions but also a leader in the Asian market. Amid the digital transformation trend, the six open-source databases it primarily used brought the total number of database instances in its production environment to over ten thousand, with a data footprint approaching the 10PB scale. This left the system facing challenges such as high system complexity, rapid data growth, high resource costs, and persistently high operations costs.

As of January 2025, Dmall had successfully launched five business databases on OceanBase, with 20T of data, covering its logistics system, settlement system, virtual system, and monitoring/snapshot slow-query analysis database, with significant cost benefits. For example, a single-replica data volume of 2.1T in MySQL shrank to 252GB after migration to OceanBase. The single-replica compression ratio is approaching an astonishing 90%. Since MySQL uses a one-primary-two-replica architecture while OceanBase uses a three-replica architecture, the combined calculation shows that OceanBase’s overall compression ratio delivers over 80% in cost savings.

(6) Yunji E-Commerce’s Cost Reduction at Scale: 87.5% Economic Cost Reduction

Yunji is an e-commerce company similar to Taobao and JD.com but more focused on social commerce, dedicated to providing members with an exceptionally cost-effective, full-category curated selection of products through a “curation” strategy, helping hundreds of millions of consumers buy quality, reliable goods at “wholesale prices.” Affected by the external environment in recent years, requirements on server and labor costs have grown ever higher. With server costs currently accounting for over 85% of total costs, there was an urgent need to reduce hardware spending, improve resource utilization, and reduce operational complexity.

By adopting OceanBase, the business shifted from the original CDB + ETL + big data architecture to a single OceanBase cluster supporting HTAP business, reducing the intermediate links in the data pipeline. A single technology stack also reduced development workload, while OceanBase’s high reliability of RTO < 8s and RPO = 0 met the requirements of MLPS (Multi-Level Protection Scheme) audits. Overall, Yunji achieved cost optimization across machines, storage, labor, and operations, reducing its peak monthly server cost from the original over 8 million to less than 1 million now—saving 87.5% in economic costs.

Summary

For enterprises, cost reduction is not optimization at a single level but full-stack collaboration across hardware + storage + software. OceanBase is committed to continuously optimizing and innovating across hardware compatibility, ecosystem usability, the storage engine, and more. Through multiple core technologies such as a high data compression ratio, multi-tenant resource isolation to reduce resource fragmentation, and encoding and compression techniques, it achieves direct cost reduction. By supporting various business needs such as HTAP hybrid engines, KV multimodality, and vectorization, it reduces operational complexity and avoids deploying multiple systems together, achieving indirect cost reduction. Through its standalone-distributed integrated architecture that adapts to the full business lifecycle, it avoids the migration cost of frequently switching databases and improves the long-term cost-performance ratio. These characteristics lead more and more enterprises to choose OceanBase, and OceanBase keeps exploring—with technical innovation as the core driving force—committed to creating greater room for enterprise cost reduction.

Finally, we recommend the WeChat official account of Lao Ji, the head of OceanBase open source: “Lao Ji’s Tech Talk,” which continuously publishes various technical content related to #Databases, #AI, and #Tech Architecture. Friends who are interested are welcome to follow!

“Lao Ji’s Tech Talk” hopes not only to keep bringing you valuable technical insights but also to contribute to the open-source community together with everyone. If you recognize the OceanBase open-source community, please light up a little star ✨! Every Star you give is the motivation for our efforts.