More Than Just Replacing HBase: How Baofu Payment Leveraged OceanBase to Build a Future-Ready, Unified 'TP+AP+KV+AI' Data Foundation

Author: Yang Ze, Head of the Baofu Payment Data Team

As digital transformation and upgrading enter a critical period, the database has evolved from a passive storage warehouse into an intelligent data hub that actively empowers business. Take the modern financial industry: business now places higher demands on the database — it must handle transactions while also performing real-time analysis, and at the same time process multi-model data securely, efficiently, elastically, and intelligently, supporting real-time decision-making and business innovation. This means a qualifying database must deliver excellent data-processing capabilities across TP, AP, KV, and AI.

As a one-stop comprehensive payment solution provider with years of deep experience across banking, consumer finance, retail, cross-border, and other industries, Baofu Payment offers a rich array of products. Deeply understanding the relationship between technological innovation and business stability, it continually brings in advanced technologies to maintain and safeguard the steady operation of the company’s business, comprehensively protecting merchants’ funds and transaction security.

In recent years, Baofu Payment’s original database solution could no longer meet business needs, so it sought a technical upgrade. This article shares Baofu Payment’s technical practice of replacing HBase with OBKV in KV scenarios.

Driven by Architectural Pain Points, Seeking a Database That Supports TP+AP+KV+AI

The group to which Baofu Payment belongs — Mandao Group — uses a centralized MySQL-based architecture. Due to rapid business growth in recent years (about 30 million transactions/day in early 2023, surpassing 90 million transactions/day by December 2024), the resulting massive data (at the TB scale) caused system pressure to surge.

The most direct pressure was cost pressure: the annual storage procurement budget reached tens of millions of yuan. At the same time, to guarantee the high availability of certain business systems, fully equivalent MySQL active-active clusters had to be deployed across two data centers, A and B (for example, 100 servers each), causing hardware and operations costs to multiply.

Moreover, under the active-active architecture, the business layer only cares that “orders aren’t lost and writes happen in real time,” but doesn’t care which data center or shard the data ultimately lands in. This posed a huge challenge for the data team: it was impossible to accurately trace the data source, making it hard to build a unified data view, and the ETL and real-time sync logic became extremely complex.

With such a wide variety of business types, long-term use of MySQL also made the architecture increasingly complex, putting enormous pressure on operations. The group internally runs more than a dozen big-data clusters and over 1,000 MySQL instances, serving different scenarios such as payment, risk control, credit reporting, and BI — each with different database needs.

• Payment transaction system: requires high-concurrency, low-latency transaction processing.
• Risk control system: relies on real-time data analysis and millisecond-level decision-making.
• Credit-reporting user-profile business: needs high-performance KV storage and fast point lookups.
• BI system: relies on large-scale offline analytical computation.

Running multiple heterogeneous systems in parallel made operations work — development, monitoring, backup, scaling, and so on — extremely heavy.

Beyond MySQL, we used HBase to store massive logs and wide tables. While it has high-throughput write capability, it has clear shortcomings in transaction support, complex queries, real-time analysis, and mixed KV workloads, and could no longer meet the needs of next-generation business.

Based on the above challenges, we began evaluating next-generation distributed database solutions. As mentioned at the start of this article, modern financial business places multiple demands on the database. Baofu Payment, as a member of the financial industry, is no exception. Based on our needs across TP, AP, KV, and AI, the first option that came to mind was OceanBase — the core reason being its native support for an integrated HTAP (hybrid transactional/analytical processing) + KV + AI architecture.

• TP capability: meets the high-concurrency, strong-consistency requirements of the payment transaction system.
• AP capability: supports the real-time analytical needs of risk control and BI.
• KV interface: provides low-latency point lookups for scenarios such as credit reporting.
• AI capability: a built-in vectorization engine and AI-native capabilities, laying the foundation for future AI applications such as intelligent risk control and real-time recommendation.

To control risk, we took a progressive “edge-to-core” transformation path: first validating OceanBase’s stability in non-critical systems, then gradually migrating mid-platform systems such as risk control and credit reporting; the ultimate goal is to smoothly switch the core payment transaction system to OceanBase, using a single database to carry all-scenario needs.

From Edge to Core: Replacing HBase with OBKV-HBase

After kicking off the OceanBase adoption plan, we first piloted it on offline and analytical business, then migrated several MySQL workloads to OceanBase. Once OBKV’s features were fairly complete, we also completed the upgrade from HBase to OBKV-HBase, achieving our goal of one engine supporting multiple business scenarios.

HBase Struggles to Handle Business Complexity and Real-Time Requirements

Although HBase once played an important role in massive-data storage scenarios, as business complexity grew and real-time requirements increased, its problems in architecture, operations, and cost became increasingly prominent — mainly in the following six areas.

• A long, redundant offline pipeline: the current data flow goes from MySQL to Hive and then into HBase, with many steps, significant data latency, and insufficiently flexible data correction at the Hive layer.
• Over-reliance in the real-time pipeline: directly reading and writing HBase relies heavily on ZooKeeper and HDFS, with high middleware coupling and concentrated pipeline-stability risk.
• Operations problems: in cross-data-center scenarios, cluster switchover and data sync operations are cumbersome, and it’s hard to quickly isolate or switch over during failures.
• Cost control: to meet high-availability requirements, a complete HBase primary-standby cluster must be deployed, nearly doubling hardware and storage resources — an excessive cost.
• Multi-data-center network problems: when the data-center network is partitioned, or when the dedicated line is abnormal, the business is affected.
• SQL queries depend on Phoenix: HBase doesn’t natively support standard SQL, so queries require components like Phoenix, introducing extra maintenance burden, and the experience and performance are often less friendly than direct SQL.

Replacing HBase with OBKV to Lay the Foundation for a Unified Tech Stack

OBKV is a NoSQL product series built on top of OceanBase’s distributed storage engine. It currently supports three product forms — OBKV-Table, OBKV-HBase, and OBKV-Redis — and natively inherits OceanBase’s foundational capabilities of high performance, transactions, distribution, multi-tenancy, and high reliability. In addition, OceanBase’s tooling (such as OCP, OMS, and CDC) also natively supports OBKV, so operating the various OBKV product forms is exactly the same as operating an OceanBase SQL cluster. OBKV can help enterprises unify their tech stack, meeting business needs for a multi-model NoSQL database while reducing the complexity of database operations.

Based on the OBKV-HBase we are currently using, we summarize the usage differences from HBase as follows.

• Full integration of OceanBase’s distributed storage capabilities: OBKV not only has OceanBase’s powerful kernel capabilities, but also inherits OceanBase’s rich ecosystem tooling.
• Minimal operations: if a DBA needs both SQL and NoSQL databases, they can operate just one database.
• Unified queries: you can use OBKV for simple, fast DML, and at the same time use SQL to run concurrent complex queries over the same data.
• Lower cost: HBase uses dedicated resources, whereas OceanBase reuses existing resources.
• More convenient monitoring: it’s easy to add monitoring to the application’s existing runtime environment.

OBKV-HBase not only solves the pain points of traditional HBase in complex operations, resource silos, and missing tools, but also — through deep integration with OceanBase — achieves the goal of a modern data infrastructure with “one engine, multi-model service, unified operations, and shared resources.”

Three Stages of Introducing OceanBase to Ensure a Smooth, Controllable Technical Transition

During the database architecture upgrade, we introduced OceanBase in three stages to ensure a smooth and controllable technical transition.

Stage One: Initial Exploration and Capability Evaluation (2023)

At the end of 2023, the team began working with OceanBase and its OBKV-HBase product. At the time, OBKV’s documentation was still incomplete and key features were missing — in particular, it lacked bulkload (batch import) capability, making it impossible to efficiently import offline data — so we initially judged that it wasn’t yet able to support core business. As a result, this stage focused mainly on technical research, with no production use.

Stage Two: Pilot in Archiving and Analytics Scenarios (2024)

In 2024, the team turned to scenarios that better matched OBKV’s current capabilities, launching a pilot of OceanBase in offline and analytical business by migrating data archiving, BI aggregation wide tables, and AP analytical business to OceanBase. We not only validated OceanBase’s stability and performance in high-throughput writes, complex queries, and resource isolation, but also accumulated key experience in cluster deployment, SQL optimization, and operations monitoring — laying the foundation for the subsequent full rollout.

Stage Three: Gradual Replacement and Expansion (from 2025)

As OceanBase’s features continued to mature (especially the maturation of OBKV-HBase), the team launched a large-scale replacement plan.

• Relational business: gradually migrate the business management system, merchant management system, BI system, and other original MySQL applications to OceanBase’s SQL mode;
• NoSQL business: replace the original HBase with OBKV-HBase — for example, migrating high-frequency KV scenarios such as “card-binding/unbinding operation logs” to OBKV-HBase;
• Achieve unified handling of TP, AP, and KV workloads, driving tech-stack convergence and simplified operations.

A Five-Step Smooth Migration: Tooling, Solution Design, and Caveats

In the process of migrating data from HBase to OBKV-HBase, we distilled five key steps from practice.

Step 1: Target-Side Preparation

Before formally starting the data migration from HBase to OBKV-HBase, you need to complete thorough environment and configuration preparation on the OceanBase side.

• Hardware configuration: to avoid cluster instability caused by insufficient disk performance, we recommend using high-performance disks — but don’t over-allocate resources at the outset, so you can reserve elastic headroom for subsequent scaling and load-balancing adjustments.
• Storage planning: the disk capacity of a single OBServer node should be larger than the data volume of a single log stream. If a single table has a very large data volume while node disks are insufficient, a “not enough space” error may be triggered during scaling or replica migration.
• Tenant planning: we recommend creating a dedicated tenant for OBKV to isolate resources.
• Set up the partitioned tables correctly.

Caveats

• Testing showed that automatic Range partitioning outperforms manually preset Hash partitioning. Automatic partitioning supports partition pruning and offers better performance for range-scan queries; manual Hash partitioning has to scan all partitions for range queries, significantly increasing latency and resource consumption.
• You must create the Table Group correctly: an HBase table name corresponds to the tablegroup name in OBKV-HBase.
• Mind the naming conventions: an HBase column family corresponds to the OBKV-HBase table form tablegroup$family.
• Mind the case of K: when exporting CREATE TABLE statements with tools like DBeaver, keywords (such as K) may be converted to lowercase (such as k), causing syntax errors. You must also explicitly set the Max Versions and the data expiration time (TTL) (multiple versions, multiple rows).

Step 2: Data Migration

After completing the target-side environment preparation, we carried out historical data migration and incremental data synchronization in phases to ensure the business switched smoothly to OBKV-HBase.

Historical Data Migration

To efficiently migrate massive historical data (a single table reaching tens of TB), we used both DataX and OMS, but you must pay special attention to the key differences between the two in data format:

• Data imported by DataX has a Q value that includes the column family, and a positive T value.
• Data imported by OMS has a Q value that excludes the column family, and a negative T value.

Incremental Data Synchronization

To ensure zero data loss during the switchover, we adopted a double-insurance mechanism of “OMS incremental sync + business dual-write”:

• Enable replication on HBase and sync incrementally via OMS.
• Use business-program dual-writing to ensure real-time data synchronization.
• Gradually switch traffic from HBase to OceanBase.

Step 3: Data Verification

Because OBKV-HBase is a NoSQL scenario, OMS in the current version does not yet provide full consistency verification for KV-type data. Combining this with our business realities, we designed a multidimensional, actionable data verification approach to ensure the data was accurate after migration.

1. Row-count verification: precisely count table rows.

HBase side: use HBase’s RowCounter tool to count the rows of the original table. Command: org.apache.hadoop.hbase.mapreduce.RowCounter 'table'.

OceanBase side: use count to tally and obtain the row count, then compare it against the HBase result.

2. Three-way data comparison: leverage Doris for content-level verification.

Since OMS does not yet support full verification in KV scenarios, we introduced Doris as a temporary comparison intermediary:

• Use DataX to sync HBase data to both OceanBase and Doris.
• Compare the data consistency across HBase, OceanBase, and Doris.

3. Sample comparison of key business fields.

Step 4: Data Access Support

After completing data migration and verification, the business system needs to access OBKV-HBase through standard interfaces. We found that OBKV-HBase is not only compatible with the HBase protocol, but also extends it with a number of advanced query and operation capabilities, significantly improving development efficiency and system flexibility.

Query Operations (Select)

• Filter: supports defining complex filter conditions built with AND and OR, pushed down to the OBKV server for filtering.
• Limit: limits the number of matching rows returned.
• IN and other syntactic sugar: IN is essentially a kind of Filter; the corresponding interface is provided to make business coding easier.
• Simple aggregation: provides aggregation-semantics interfaces for Sum/Min/Max/Avg/Count, pushed down to the OBKV server for simple aggregation.
• OrderBy: only supports ordering by primary key and index.
• Iterator-style access: provides an iterator-like streaming Query interface, suitable for streaming retrieval and processing of large result sets, such as pagination scenarios.

Data Operations

• Insert: supports single-row/multi-row data insertion.
• Update: supports single-row/multi-row data updates, including conditional updates with a Filter.
• Delete: provides data deletion by primary key, supporting single-row/multi-row deletion.
• Upsert (insertOrUpdate): the semantics of this interface are — if a matching record exists, perform an Update; if not, perform an Insert. This interface also supports single-row/multi-row operations.

Step 5: Business Stress Testing

To ensure OBKV-HBase could meet the requirements of a high-concurrency production environment, we used real business workloads to stress-test OBKV performance, reaching 420,000 QPS at around 1ms latency — exceeding expectations.

Stress-test method:

• Business directly connects to OBServer to stress-test OBKV performance.
• Compare the performance difference against the earlier stress test through ODP.
• Record detailed test data.

We deployed 10 Pods to simulate business clients and ran multiple rounds of stress-testing tasks via OCP unified scheduling and via ODP. Below are the data records for OceanBase, the OCP mode, and the ODP mode, respectively.

The OceanBase stress-test data is shown in the figure below.

The OCP-mode stress-test data is shown in the figure below.

The ODP-mode stress-test data is shown in the figure below.

It’s worth noting that the earlier stress test through ODP had poor performance, with QPS below 2k; the specific cause analysis is given in the later problem summary. After optimization, stress-testing OBKV by directly connecting to OBServer reached 420,000 QPS at around 1ms latency, fully meeting business needs.

The test results from directly connecting to OBServer gave us full confidence in OceanBase’s performance, laying the foundation for the subsequent formal switchover of the business.

OBKV Launch Experience and Problem Summary: Operations Configuration and Data Verification

During the testing and launch of OBKV-HBase, we accumulated a series of practical experiences in monitoring integration, hardware configuration, tenant isolation, CDC synchronization, and more, summarized below for your reference.

Operations Configuration

1. Monitoring Configuration

To avoid duplicating monitoring-platform construction, we integrated OBKV-related metrics into the company’s unified, in-house monitoring system:

• ODP’s Prometheus parameters can use the default configuration directly, with no extra adjustment needed;
• If you need to modify ODP monitoring parameters, you can log in to the cluster via the sys tenant and run the following commands:

show proxyconfig like "%prometheus%";
alter proxyconfig set xxx = xxx;

2. Hardware Configuration

• We recommend using high-performance disks to guarantee high-throughput write needs.
• Don’t allocate too many resources at the outset — avoid assigning all of a server’s CPU/memory resources to a tenant, so you can reserve elastic headroom for subsequent scaling and load balancing.
• A single node’s disk should be larger than the log stream size. When a single table is very large and not properly partitioned, its corresponding log stream may exceed a single node’s disk capacity; and during cluster scaling (such as expanding from a 3-3-3 architecture to 6-6-6), replica migration will fail because the log stream fails to migrate to the node’s disk.

3. Tenant Configuration

We recommend creating a dedicated tenant for OBKV to avoid sharing resources with TP/AP-type SQL business.

4. CDC Configuration

When using OMS or CDC for data synchronization, you must pay special attention to the compatibility between HBase’s dynamic-column model and the CDC log format. The columns of an HBase table are dynamic (different Rows can contain different columns), whereas OceanBase’s clog (commit log) has two modes when recording changes.

• Full-column mode (full): records the values of all columns in the entire row.
• Non-full-column mode: records only the updated fields.

If the source writes in non-full-column mode while the target CDC expects full-column logs, it may cause sync-parsing failures or data inconsistencies.

The solution is to enable CDC’s dirty-data skip switch skip_dirty_data=1, which allows skipping full-column verification; restart the instance after the change for it to take effect: ALTER BINLOG INSTANCE y6op8d9rk1 SET EXTRA_OBCDC_CFG ='skip_dirty_data=1'.

5. Use setRowPrefixFilter for Prefix Retrieval

In the early research phase, we were rather worried about whether OBKV-HBase supported efficient queries based on RowKey prefixes. After thorough documentation review and testing, we confirmed that OBKV-HBase is fully compatible with HBase 1.2+’s native API, including the key prefix-retrieval feature. You can use the Scan.setRowPrefixFilter(byte[] prefix) method to achieve an efficient Prefix Scan, as shown in the figure below.

This interface automatically constructs the start key (startRow) and stop key (stopRow), scanning only the RowKey range matching the specified prefix, avoiding a full-table scan and significantly improving query efficiency.

Data Verification Problems

In the process of migrating from HBase to OBKV-HBase, we also encountered three key problems during data verification.

Problem 1: Upstream-Downstream Row-Count Reconciliation

Problem description

After migrating the same HBase table using DataX and OMS separately, the data row count in OBKV was lower than in the HBase source in both cases, and initial verification couldn’t be reconciled.

Cause analysis

HBase’s data-model characteristics make the count result ambiguous.

• Region split overlap: during splitting, duplicate RowKeys may be briefly produced.
• Uncommitted data / failed-write residue: some writes didn’t complete but the log was already persisted.
• Multi-Version: the same RowKey written multiple times produces multiple timestamped versions, all retained by default.
• TTL (Time-To-Live) not yet in effect: expired data hasn’t been cleaned up yet and is still counted.

In the above scenarios, HBase’s RowCounter counts all versions + all visible records, whereas OBKV by default retains only the latest version (if not explicitly configured), leading to the count discrepancy.

Solution

• Standardize the migration tool: avoid mixing DataX and OMS, to prevent deviations caused by their differing handling of timestamps and column formats.
• Abandon the Snapshot- or HFile-based BulkLoad approach, switching to queryType=scan streaming reads to ensure only the currently visible, committed, latest-version data is synced.
• Develop a dedicated data verification tool to compare source-side and target-side data.

Result verification

By adjusting the migration tool and verification method, we ultimately achieved complete consistency between HBase and OBKV data.

Caveats

• CREATE TABLE statements are case-sensitive: in CREATE TABLE statements exported via tools like DBeaver, the K keyword may be lowercase (such as k = 'value') and must be manually corrected to uppercase, otherwise parsing fails.
• Mind setting the max version number and expiration attributes (multiple versions, multiple rows).

Problem 2: Error Code 20002

Problem description

• The client waited for the server with no response packet and timed out with error 20002; the default timeout is set to 1.5 seconds.
• After each application restart, the first query took relatively long, while subsequent queries were basically normal.

Cause analysis

The root cause was an unreasonable scan.setCaching parameter configuration.

• The scan.setCaching parameter limits the number of rows returned per RPC request. During next() iteration, the underlying layer pulls the remaining data via multiple RPCs.
• When scan.setCaching is not set, a single RPC pulls an entire partition’s data by default, and the process stalls while waiting for the data to return, resulting in high RT.

Solution

Set the scan.setCaching parameter to 100 to control the maximum number of rows returned per RPC request: scan.setCaching(100);. After setting this, the first query time dropped to around 300ms, and subsequent query performance also improved significantly.

Problem 3: Poor Proxy Stress-Test Performance

Problem description

Stress-testing OBKV-HBase through ODP revealed a clear performance bottleneck, with QPS below 2k.

Cause analysis

The root cause was a mismatch between ODP’s metadata caching mechanism and the database’s case-sensitivity configuration.

• The OceanBase cluster had table-name case sensitivity enabled (lower_case_table_names = 0).
• ODP’s default behavior, however, didn’t correctly recognize the case-sensitive context when handling metadata requests, so it couldn’t effectively cache the table schema information.

Every query triggered the full metadata-parsing flow (including querying the table definition from the sys tenant) and couldn’t hit the local cache. The high-frequency metadata queries became the performance bottleneck, severely dragging down overall throughput.

Optimization plan

• Enable ODP’s lowercase table-name compatibility mode by setting the ODP parameter, executed under the sys tenant: alter proxyconfig set pc_enable_lower_case_table_names=True.
• Re-running the stress test: QPS stabilized at around 12k, a 6x performance improvement.

“One Database, Multi-Model; A Unified Platform” — Introducing OceanBase at Scale

Through nearly two years of in-depth practice with OceanBase and its OBKV-HBase capabilities, Baofu Payment successfully completed a smooth evolution from a traditional HBase architecture to a next-generation distributed database platform, achieving significant technical and business results.

• Cost reduction: by switching from HBase’s dedicated resources to OceanBase’s shared resources, we not only freed up several servers’ worth of resources, but also achieved unified handling of NoSQL and SQL workloads, substantially reducing hardware investment and operations costs.
• Efficiency gains: QPS rose to 420,000 and latency dropped to around 1ms, fully meeting the stringent SLA requirements of high-concurrency payment scenarios.
• Improved availability: we said goodbye to complex architectures such as MySQL primary-replica + remote standby, unifying everything into OceanBase’s multi-replica, strongly consistent architecture. The system has automatic failover (RTO < 8s) and zero data loss (RPO = 0) capabilities, significantly improving overall robustness.
• Unified monitoring: it’s easy to add monitoring to the application’s existing runtime environment, greatly improving observability and ease of monitoring.

Not only that, this also holds major significance and value for the group’s architecture.

First, a comprehensive database-architecture upgrade. From HBase to OceanBase, from “multiple heterogeneous databases” to “one database, multi-model, a unified platform,” we achieved a comprehensive database-architecture upgrade and substantial tech-stack convergence.

Second, solidifying the foundation for business innovation. High-performance, highly available data services provide stronger data support for business innovation in new scenarios such as real-time risk control and intelligent BI.

Third, laying the foundation for an intelligent data architecture. This reserves ample room for future evolution directions such as AI-native computing, HTAP-fused analytics, and cross-region active-active.

Fourth, accumulating valuable hands-on experience. We formed a complete methodology covering migration solutions, data verification, performance tuning, and troubleshooting, which can be reused in subsequent system transformations.

This successful rollout of OBKV-HBase would not have been possible without the professional, timely, and in-depth technical support the OceanBase team provided over the past two years — especially Lao Ji and his R&D and technical-support teams. Whether it was early feature customization, tackling performance bottlenecks, or production-launch support, the OceanBase team stood shoulder to shoulder with us throughout, providing solid assurance for the project’s smooth progress. Here, on behalf of the Baofu Payment technical team, I extend our sincere thanks to the OceanBase team for the technical support provided during the migration!

In addition, based on OceanBase’s current successful rollout at Baofu Payment, we have made OceanBase a core part of the group’s future data architecture, focusing on four business directions for large-scale adoption: AI project enablement, consolidation-store construction, active-active architecture experimentation, and retail-payment scenarios.

1. AI project enablement: achieving integrated SQL+AI.

To respond to the company’s strategic push for intelligent transformation, we will deeply integrate AI capabilities into the database engine layer, driving an upgrade from “passive querying” to “proactive intelligent service.”

• Native support for AI hybrid computing: leverage OceanBase’s built-in vectorized execution engine and AI-function capabilities to achieve “SQL + AI” hybrid computing.
• Explore intelligent query optimization and data processing.
• Improve data-analysis and decision-support capabilities.

2. Consolidation-store construction: achieving integrated TP+AP.

The group currently has 1,000+ MySQL instances and multiple heterogeneous data systems, posing huge challenges for scenarios such as cross-database analysis, real-time statistics, and operational reporting. OceanBase’s integrated HTAP architecture provides a fundamental solution. We will gradually migrate core business stores, consolidation stores, and wide tables to OceanBase and expand its online usage, using a single cluster to carry both TP writes and AP analytics, building a unified data platform, simplifying the data pipeline, and improving data governance and data-service capabilities.

3. Experimenting with an active-active architecture for system stability.

Frustrated by the problems of MySQL’s active-active architecture, we will experiment with multi-active business requirements to meet high-availability needs. Relying on OceanBase’s native distributed multi-replica capability and the Paxos protocol, we will build a lightweight, highly available, cross-data-center, cross-region active-active architecture, improving the system’s disaster-recovery capability and business continuity.

4. Deepening retail-payment scenarios.

As internal retail-payment business grows, we will promote OceanBase across other retail-payment business scenarios, while continuing to optimize OceanBase stress-test records and refine performance baselines. We plan to conduct regular stress testing based on real business workloads, establishing baseline models for key metrics such as QPS, latency, and resource consumption.

In addition, we will explore more OceanBase application scenarios in the payment industry, fully leveraging OceanBase’s HTAP and multi-model capabilities.

A database upgrade is not just a technical iteration — it is the cornerstone of continuous business innovation and steady operation.