China Unicom's ChatDBA Upgrades Its Vector Database: A Hands-On Comparison of Milvus, Elasticsearch, and OceanBase

This article is adapted from the 2025 OceanBase Developer Conference talk “How China Unicom Uses OceanBase to Reshape the Future of Intelligent Database Operations”; click the link to watch the recording.

With the rapid development of information technology, the database—as the core of enterprise data management and analysis—is becoming ever more important. As a leading domestic telecommunications service provider, China Unicom, in order to cope with challenges such as the surge in data volume and the diversification of business needs in the course of its development, has been actively exploring innovative applications of database technology, especially in the field of intelligent operations.

This article will explore in detail why China Unicom chose OceanBase’s vector capabilities to build an intelligent operations platform, and share its selection comparison among Milvus, Elasticsearch, and OceanBase.

1. Background: Building a Database Product and Operations System

Against the backdrop of making core technologies autonomous and reliable, China Unicom took the lead in launching an internal-system reliability strategy, planning to complete a full architectural overhaul by 2027. The aim is to improve the security and reliability of its information systems and reduce its reliance on external technology by adopting domestic, autonomous, and reliable technologies and products.

(1) A Self-Developed + Commercial Database Product System

Against this backdrop, and to address the discontinuation risk of MySQL 5.7, reduce reliance on commercial products, and strengthen the software capabilities of its software research institute, China Unicom—three years ago—chose to build its own distributed CUDB product based on OceanBase Community Edition, while also rounding out its database product ecosystem. China Unicom subsequently introduced several commercial database products, forming a self-developed + commercial database product system that solved core database technology problems, supported the group’s architectural upgrade, and completed the internal-system reliability strategy.

In building its database product ecosystem capabilities, to shield the differences between underlying databases and improve operational efficiency, China Unicom established the cross-database CDAS (Cloud Database Autonomous System) tool system. It provides a unified operations and management view, and is a self-developed database autonomous-service tool that integrates across products and masters every scenario, achieving autonomous full-lifecycle management of databases, reducing manual intervention, and improving database performance, stability, and security.

(2) Building Intelligent Operations for the Database Platform—ChatDBA

To better serve applications, lower the barrier to using databases, and improve operational efficiency, China Unicom focused on full-lifecycle database DevOps management, combining AI large models with database expert experience to build ChatDBA, an intelligent database expert.

Built on large models and fine-tuned models, ChatDBA constructs a multi-Agent orchestration and scheduling engine, integrates various mature tools, and empowers the full lifecycle of the database.

• In the design phase, ChatDBA plans capabilities for model design, schema design, and intelligent database and table creation;
• In the development strategy phase, ChatDBA prioritizes capabilities for SQL generation and completion, SQL-to-code conversion, and heterogeneous SQL conversion;
• In the go-live phase, ChatDBA prioritizes capabilities such as SQL review and index check and optimization;
• In the operations phase, ChatDBA uses means such as logs and monitoring to achieve root-cause localization and rapid recovery;
• In the later operations phase, ChatDBA prioritizes SQL tuning functionality.

These capabilities allow the database to better serve applications. Let’s introduce three scenarios in detail: database development, database operations troubleshooting, and DBA knowledge Q&A.

Scenario 1: Database development.

In the database development phase, applications may face many problems, such as: hand-written SQL is not only time-consuming but also error-prone, and a new database has a high barrier to use with uneven SQL quality. To address this, China Unicom combined large models with Agent capabilities to build capabilities such as Text2SQL, SQL-to-code conversion, and heterogeneous SQL conversion, improving the accuracy of generated results through continuous debugging and thereby improving development efficiency. In addition, by building database agents and combining them with the CDAS tools, the agents gain professional execution ability and can autonomously make decisions and take action based on instructions.

Scenario 2: Database operations troubleshooting.

In the database operations phase, operations staff may face the problem of needing to manually analyze information such as logs and monitoring data, which is time-consuming and inefficient. To address this, based on large language models and Agents, China Unicom built a database operations troubleshooting assistant around core operations scenarios such as fault discovery, fault diagnosis, and fault handling. By gathering common operations knowledge—including experience and faults—and feeding that knowledge in via a vector database, it cultivates the Agent’s professional operations capabilities. In addition, through multi-Agent orchestration and scheduling, Agents from each domain work together to improve operational efficiency.

Scenario 3: DBA knowledge Q&A.

Throughout the full lifecycle of a database, product staff and developers may face challenges such as many applications, many problems, and rapid iteration—they not only need to keep learning, but also need their problems resolved promptly. To address this, China Unicom reused the knowledge-processing capabilities of its R&D large model, focusing on professional knowledge in the database domain and product operations support knowledge, and built a DBA knowledge Q&A capability based on the CDAS database ecosystem. First, it collects professional knowledge documents and—through document splitting, chunking, and vector generation—enables the large language model to acquire professional database-domain knowledge. Second, through vector search, it helps the large language model generate more accurate and richer text content, improving the efficiency and quality of text-processing tasks. Through this approach, it ultimately provides one-stop, high-quality technical consulting and solution services for database users (application staff) and database maintainers (product operations and support staff).

2. Choosing OceanBase to Power Intelligent Operations

(1) The Technical Challenges of an Intelligent Operations Platform

A key foundational component is used across all the usage scenarios of the intelligent database expert ChatDBA: the vector database.

At first, in implementing ChatDBA, China Unicom used MySQL to process data and Milvus for retrieval, but this had the following problems.

• Single-point problem: since MySQL is a centralized database that can only be deployed standalone, it has a single point of failure; Milvus, currently in a non-k8s environment, can also only be deployed standalone—leaving significant hidden risks to system availability.
• Scalability problem: constrained by the standalone deployment architecture, in the early stage of going live, when the business volume was low, resources were severely wasted; and as the business volume grew, it could not scale horizontally.
• Operational complexity problem: operating multiple database components at the same time was fairly complex, and since Milvus depends on components such as MinIO, operating costs rose sharply.

China Unicom therefore turned its attention to other vector databases in the industry whose functionality and architecture were a better fit.

(2) Vector Database Selection

1. Comparing products in the industry.

China Unicom conducted a preliminary survey of mainstream vector database products on the market, focusing especially on three products that have drawn a lot of attention: Milvus, Elasticsearch, and OceanBase. Here are the detailed findings.

• Basic vector capabilities: for things like basic vector queries, all three—Milvus, Elasticsearch, and OceanBase—essentially support them.
• Vector dimensions: OceanBase supports up to 16,000 dimensions; Milvus supports up to 32,768 dimensions (but not directly via SQL); Elasticsearch supports up to 4,096 dimensions.
• Data consistency: OceanBase supports transactions and can guarantee data consistency, while Elasticsearch and Milvus cannot.
• Product deployment: the latest versions of all three databases currently support both standalone and distributed deployment modes, but OceanBase is a natively distributed architecture and can be transparent and elastic.
• Backup and recovery: Milvus supports only full backups of data; Elasticsearch supports full and incremental backups; OceanBase supports full backups, incremental backups, and transaction log backups. In addition, Milvus and Elasticsearch can only restore data to the point in time of the backup, while OceanBase supports restoring to any point in time.
• Other aspects: Milvus lacks monitoring/inspection interfaces and multi-modal capabilities, with no plans to support them later; combined with its weak permission management, its overall operational usability cannot adequately meet business needs.

2. Benchmark performance testing.

Vector database performance is also a key focus for China Unicom, so it ran benchmark performance tests on the above vector databases. The test environment was a domestic ARM environment, using a standard dataset and the professional vector database testing tool VectorDBBench. Here are the performance test results.

On a 768-dimension, 1-million-record dataset, OceanBase’s overall performance is better than Milvus’s; at the same recall:

• When recall is in the 0.74–0.98 range, OceanBase’s performance is roughly 3x that of Milvus;
• When recall is 0.98, OceanBase’s performance even reaches 6x that of Milvus.

OceanBase’s overall performance is also better than Elasticsearch’s; when recall is in the 0.74–0.98 range, OceanBase’s overall performance is about 70% higher than Elasticsearch’s.

On a 1536-dimension, 500,000-record dataset, OceanBase’s overall performance is better than Milvus’s. As shown in the figure below, when recall is in the 0.87–0.99 range, OceanBase’s performance is about 60% higher than Milvus’s, and its overall performance is on par with Elasticsearch’s.

3. Validation summary.

In summary, the differences among Milvus, Elasticsearch, and OceanBase in functionality, performance, and product ecosystem are roughly as follows.

• Functionality: Milvus does not support hybrid queries; Elasticsearch supports only hybrid queries over vector and full-text indexes; while OceanBase supports very comprehensive vector query capabilities including vector, scalar, GIS, full-text indexes, and hybrid queries.
• Performance: OceanBase is overall better than Milvus and Elasticsearch. At the same recall, OceanBase is 1.5–3x Milvus, and its overall performance is about 40% higher than Elasticsearch’s.
• In terms of product ecosystem, OceanBase has clear advantages:
  • OceanBase’s management tools can directly enable GUI-based monitoring alerts, backup and recovery, and more;
  • Because OceanBase is a natively distributed architecture, it supports rapid recovery from single-machine failures and has native high-availability and elastic scaling capabilities, enabling transparent elastic scaling and transparent load balancing;
  • OceanBase has multi-tenant resource isolation capabilities, which—combined with its powerful scalability—can provide secure and flexible DBaaS services, greatly simplifying the architecture and easing operations.

Based on OceanBase’s comprehensive advantages in the comparison and validation, China Unicom decided to choose OceanBase as its target vector database, and—leveraging OceanBase’s multi-modal support—upgraded the architecture away from MySQL and Milvus.

(3) Program Adaptation and the Results of the Upgrade

During the architecture upgrade, China Unicom first adapted its programs. Since OceanBase is fully compatible with MySQL syntax, MySQL only needed a simple change to the connection address to complete the upgrade. At the same time, OceanBase supports both SDK and SQL access methods and provides an SDK interface compatible with Milvus, so the effort to replace Milvus was not large either. As a result, China Unicom completed all program adaptation and validation in just half a month.

In terms of data migration, OceanBase’s official migration service OMS supports full and incremental data migration from MySQL to OceanBase, as well as full migration from Milvus to OceanBase. The entire migration process was very smooth and took little time.

After completing the architecture upgrade, the results were significant, especially in resource utilization, stability, and scalability.

• Resource utilization: after replacing the business previously supported by two databases with the integrated OceanBase, the spec was reduced by 30%, bringing 30% resource savings.
• Stability: OceanBase is a multi-node architecture and can achieve RPO=0, RTO<8s in the event of a single-machine failure, avoiding the business availability and data loss risks of the original architecture.
• Scalability: OceanBase can flexibly adjust its spec based on the business load, achieving the utmost in resource utilization; even when the entire cluster is under heavy load, it can scale horizontally to meet demand, and all operations are completely transparent to the application.

Overall, this architecture overhaul not only achieved a technical upgrade, but also brought additional benefits such as resource savings, stronger stability, and transparent elastic scaling—leaving China Unicom’s internal business staff, R&D staff, and operations staff all very satisfied.

3. Looking Ahead

In the future, China Unicom will build a vector database resource pool, unify its vector database technology stack, uniformly empower knowledge base RAG scenarios, and explore OceanBase’s vector capabilities. OceanBase is also continuing to optimize and refine its vector support capabilities—for example, supporting binary distance and more index types, as well as further improving vector index build speed, enriching vector search capabilities, and supporting GPU acceleration. Building on its deep collaboration with the OceanBase community and the results achieved so far, China Unicom hopes to continue collaborating on vector database R&D and to further enrich the community ecosystem.