Stop Following the Crowd Blindly: The Core Principles Behind Seven Companies' Real-World Vector Database Choices

Since taking charge of OceanBase’s open-source business, I’ve seen far too many companies make technology selection decisions. Anyone who has made architecture decisions knows that technology selection is never an academic exercise—it’s a comprehensive contest between business pain points, cost pressure, and operational capability. Recently, we systematically reviewed the real thinking and practice of seven companies in their vector database selection. Across different scenarios, they all compared Milvus and OceanBase, and although Milvus has a stellar reputation in the vector search space, these companies ultimately all chose OceanBase. Why? This article presents these companies’ selection logic, implementation paths, and quantified outcomes exactly as they happened, providing replicable decision-making references for teams currently evaluating vector databases.

Note: The product versions tested and compared during these companies’ selection processes were 2024-2025 versions, not the latest 2026 versions. Please focus on the companies’ selection logic. If you want to learn about the latest versions and features of the products mentioned, please consult the respective product websites.

Introduction: Three Illusions of Vector Database Selection

In 2024, as AI applications moved from demo to production, many technical teams went through a similar shift in understanding. Early on, we were drawn to the specialization of vector databases, believing that purpose-built tools would inevitably deliver the best performance. But after running them in production for a while, we discovered three harsh truths:

Illusion one: performance is only about raw vector search QPS. In the lab, the HNSW index of a dedicated vector database is indeed fast, but when your query needs to carry three conditions—“time range > business attribute > vector similarity”—the end-to-end latency will make you question everything.

Illusion two: operations is just setting up a K8s cluster. When you actually need to guarantee RPO=0, handle etcd split-brain, and coordinate cross-cloud dedicated-line failures, you’ll understand that financial-grade stability is no idle boast.

Illusion three: cost is only about server prices. When your team needs 2 dedicated SREs to maintain a vector cluster, spends 40 hours a month dealing with data inconsistency, and the CEO starts asking “why is the AI project over budget by 300%,” the true face of TCO surfaces.

The stories of these seven companies begin precisely with shattering these illusions.

I. Real Pain Points in Production Environments

Qihoo 360’s Operations Nightmare: From Component Explosion to Monitoring Black Hole

When Qihoo 360’s commercialization business line introduced AI capabilities, the first thing it thought of was Milvus. After all, it has tens of thousands of stars on GitHub, and the community looks active. But the technical lead quickly found that “Milvus involves a great many components managed by K8s, and each component needs monitoring. The monitoring pipeline is fairly complex, and the operations staff also face the learning cost of K8s and all the various components.”

This isn’t a simple learning-cost problem. When advertisers crowd in to query real-time reports at 9 a.m., the Milvus cluster’s etcd starts to show write latency, and the vector search service’s response time spikes from 50ms to 500ms. Worse still, the Canal sync pipeline’s latency meant advertisers were seeing data from 2 seconds ago, directly affecting their delivery decisions.

“We did the math: to keep the Milvus cluster stable, we needed at least 1.5 dedicated SREs. With OceanBase, we can directly reuse our existing MySQL operations experience—0.5 of a person part-time gets it done,” the Qihoo 360 technical lead admitted.

China Unicom’s Stability Crisis: When Single Points of Failure Meet Cross-Cloud Deployment

When China Unicom’s Software Research Institute built ChatDBA, it initially also adopted a “MySQL + Milvus” combination. But it soon discovered two fatal problems.

Single-point problem: In a non-K8s environment, Milvus can only be deployed standalone, posing a single-point risk. Yet the ChatDBA service needs to serve hundreds of internal users, with an availability requirement of 99.95% or higher.

Cross-cloud deployment dilemma: Unicom uses a multi-cloud architecture, and Milvus requires duplicate builds across clouds, while Zilliz’s cloud version is deployed across regions from Unicom’s online services, creating stability risks.

“In our test on a 768-dimension, 1-million-record dataset, OceanBase’s performance was 3x that of Milvus; at a recall of 0.98, performance reached 6x that of Milvus. But that still wasn’t the key. What truly made up our minds was Milvus’s shortcomings in backup and restore—it only supports full backups and can’t restore to an arbitrary point in time,” the Unicom architect said at the review meeting. Zuoyebang, which also uses a multi-cloud architecture, said the same: “We initially leaned toward purchasing cloud services to quickly meet business needs, but our AI business sees 10TB-level daily data growth, and storage cost pressure shot up. Self-built multi-cloud Milvus deployment requires duplicate builds, and the DBA team’s investment of effort and cost was too high.”

By contrast, OceanBase’s Paxos three-replica synchronization, RPO=0, and RTO<8 seconds allowed the ChatDBA platform to achieve zero downtime during a subsequent data-center-level failure.

Lalamove’s Architecture Debt: The Pain of Dynamic Schema and Hybrid Search

When Lalamove’s technical team re-evaluated its options at the end of 2024, it listed three major pain points with Milvus.

Cumbersome dynamic schema: “Frequent field additions and deletions became the norm. The current workaround is to create a new table, import the existing data, and finally rebuild the index—a relatively cumbersome process. For some tables with large data volumes, rebuilding the index can take more than ten hours.”

Missing hybrid search capability: “Relying on a single search method alone struggled to meet the business’s high precision requirements. To make up for the deficiencies of full-text search, we introduced Elasticsearch as the full-text search engine, which also increased the overall architectural complexity and raised the system’s maintenance difficulty.”

High operational difficulty: “Weak stability, insufficient scalability, weak permission and authentication capabilities, and mediocre community activity.”

These three pain points point straight at Milvus’s architectural nature: it is an engine focused on vector search, not a complete database system. When the business needs triple filtering on “vector similarity + time range + business attribute,” Milvus can only recall data, and the application layer has to implement complex reranking logic itself.

OceanBase’s SQL engine, meanwhile, can automatically perform index merging and vectorized pushdown, bringing Lalamove’s measured hybrid query latency down from 450ms to 95ms.

II. Not Just “Another Vector Database”

The Fundamental Difference in Architectural Philosophy

The difference between Milvus and OceanBase is essentially the difference between “tool thinking” and “platform thinking.”

Milvus’s design philosophy is: vector search is a standalone problem that needs a dedicated tool to solve. So it built a complete closed loop, from etcd metadata management and MinIO object storage to independent query nodes.

OceanBase’s design philosophy is: vectors are just another data type that ought to be managed by a unified database. So it added a Vector type at the storage layer and vector indexes at the index layer, fully reusing existing capabilities like distributed transactions, multi-replica synchronization, the SQL optimizer, and the OCP operations platform. OceanBase isn’t trying to build a better Milvus; it’s trying to build a more general-purpose database that lets enterprises forget that the standalone category of “vector database” even exists.

This philosophical difference brings three engineering advantages.

Advantage one: consistency isn’t a patch—it’s in the DNA.
When a Qihoo 360 advertiser updates a creative asset, the structured data (title, price) and vector data (embedding) are committed in the same transaction. OceanBase’s Paxos protocol guarantees that both take effect together or roll back together. Milvus, by contrast, has to sync via CDC, leaving an unavoidable latency window.

Advantage two: query optimization isn’t a hack—it’s native.
Ctrip’s technical team found that when a query contains the three conditions “departure=’Shanghai’ AND price<2000 AND vec_distance(feature, ?)<0.8,” OceanBase’s optimizer automatically chooses an index-merge strategy, filtering the candidate set from 1,000 rows down to 100 before performing the vector computation. Milvus, by contrast, must first recall 1,000 rows and let the application layer filter them—a 10x difference in network transfer volume.

Advantage three: operations isn’t a burden—it’s reuse.
Quwan Technology’s DBA said: “OceanBase is highly compatible with MySQL syntax, so our operations platform, monitoring scripts, and backup strategies can be reused at almost zero cost. Milvus, on the other hand, requires relearning etcd operations, MinIO backups, and SDK monitoring, and that learning curve gave us pause.” Furthermore, “Adopting the three separate systems of MySQL + Elasticsearch + Milvus means high hardware investment and high human operations costs, which doesn’t align with the ‘low-cost, fast go-live’ goal.”

Hidden Easter Eggs of Technical Depth

Beyond vector capabilities, OceanBase also offers several “hidden Easter eggs” that Milvus lacks, which become decisive factors in specific scenarios.

1. RoaringBitmap: making multi-dimensional analysis 100x faster. When Huishitong Technology processes 1 billion vehicle alert records per month, it uses OceanBase’s RoaringBitmap type to aggregate the data volume from 1 billion records to 2,000 per day, bringing query latency from >5 seconds down to milliseconds. This is a capability Milvus cannot provide.
2. Columnar storage: letting AP queries not slow down TP. During its evaluation, Weibo found that OceanBase’s columnar replicas can meet lightweight analytics needs without adding components. Milvus’s pure-vector architecture cannot support AP queries and must sync data to a separate analytics system.
3. Multi-tenancy: boosting resource utilization 3x. Zuoyebang’s DBA did the math: a Milvus cluster’s day-to-day utilization is under 15%, yet during major promotions it needs to scale up 5x. OceanBase’s multi-tenant architecture lets vector queries and TP business share a cluster, raising resource utilization to over 60% and directly saving 70% in server costs.

The Long-Term Value of Community and Ecosystem

For enterprises, the activity and richness of the community and ecosystem are reference factors during selection. In Lalamove’s view, while Milvus’s community is active, it is concentrated mainly at the algorithm level. OceanBase’s community, by contrast, is backed by Ant Group, and the community “regularly updates vector capabilities and performance and provides technical support.”

More importantly, OceanBase’s ecosystem toolchain (OCP, OMS, ODC, obdiag) has been refined over many years—precisely what Quwan Technology valued: “providing GUI-based, automated cluster management capabilities that significantly reduce daily operations complexity.”

This ecosystem gap can’t be closed in the short term. When an enterprise needs 24/7 technical support, the responsiveness of OceanBase community edition’s technical support becomes key.

Selection reference factors are multifaceted. Based on the research and testing of these seven companies, the differences between Milvus and OceanBase are summarized as follows.

Dimension	Milvus	OceanBase
Product positioning	Dedicated vector database	General-purpose multi-model database
Overall architecture	Storage-compute separation + microservices	Standalone-distributed integration + SN/SS integration
Data types	Pure vector	Vector + structured + time-series + JSON + GIS + Bitmap
Query language	Python/Go SDK	Standard SQL + Milvus SDK compatible
Hybrid query	Not supported, requires application-layer implementation	Native SQL support, engine-layer optimization
Transaction support	None	Full ACID, vectors participate in distributed transactions
Index types	HNSW, IVF, SCANN, sparse vector index, DiskANN, GPU index	HNSW, IVF, sparse vector index
ACID	No	Yes
Default consistency	Bounded	Strong consistency
Availability	Weak, depends on K8s orchestration, RPO>0	Excellent, Paxos protocol, RPO=0, RTO<8s
Operational stability	Many components, complex, impacts stability	Few components, integrated, favors stability
Hardware cost	Dedicated cluster, utilization <20%	Multi-tenant co-location, utilization >60%
Labor cost	1-2 dedicated people	0.5 person part-time, reusing DBA experience
Monitoring tools	Must be self-built, scattered metrics	Unified OCP platform, GUI-based operations
Backup and restore	Full backup, RPO>0	Full + incremental + log, RPO=0
Number of components	4+ (etcd, MinIO, query nodes, data nodes)	Single database process
Deployment	Depends on K8s or complex manual deployment	Supports unified standalone, cluster, and multi-cloud deployment
Multi-cloud support	Requires duplicate builds	Native support, unified tech stack

III. The Selection Logic of Seven Companies

Qihoo 360’s Decision Logic: The Dual Pressure of Cost and Efficiency

Qihoo 360’s commercialization business line went through a very representative selection process. They initially chose Milvus on the intuition that “professional tools do professional jobs.” But they quickly found the cost prohibitive.

Explicit cost: 8 servers + 2 SREs + 1 monitoring system = RMB 870,000 per year.
Implicit cost: advertising compensation from data inconsistency, slow iteration from operational complexity, and business losses from failure recovery time.

“We calculated that although OceanBase’s initial investment looks high, its TCO is only 1/3 of Milvus’s. More importantly, it lets us focus on business innovation rather than firefighting every day,” the Qihoo 360 technical lead summarized.

Their decision formula was: ROI = (business efficiency gains + cost savings) / (learning cost + migration cost)

In the end, OceanBase’s MySQL compatibility brought the learning cost close to zero, while the migration cost was kept within 2 weeks via a dual-write approach. With ROI>3, the decision made itself.

It’s worth noting that Quwan Technology’s cost decision was similar: “Adopting the three separate systems of MySQL + Elasticsearch + Milvus means high hardware investment and high human operations costs, which doesn’t align with the ‘low-cost, fast go-live’ goal.”

Unicom Software Research Institute’s Decision Logic: Stability Above All

As a leading Chinese telecom service provider, Unicom’s selection standards were exceptionally stringent.

“When Milvus is paired with MySQL, there’s a single-point problem—it can only be deployed standalone, posing a significant risk. On data consistency, Milvus cannot guarantee transactional consistency.” Furthermore, Milvus only supports full backups and can’t restore to an arbitrary point in time. “We have an internal rule that core systems must satisfy RPO=0. Milvus’s architecture can’t do that, whereas OceanBase’s Paxos is a native capability requiring no additional configuration,” the Unicom architect said.

This decision reflects a core principle of large enterprises: requiring both technical advancement and architectural robustness.

Lalamove’s Decision Logic: Scenario Fit First

Lalamove’s selection process placed the greatest emphasis on “scenario fit.” They listed 10 candidate products and went through three rounds of screening.

“We don’t chase ultimate performance—we chase ‘nothing goes wrong.’ Milvus’s poor community activity and low update frequency made us worried about long-term maintenance,” Lalamove’s technical lead admitted.

Weibo’s Decision Logic: A Long-Term Evolution Perspective

Weibo’s evaluation framework is worth learning from.

Current state assessment:

• High cost of using Milvus, complex management
• Performance bottlenecks in high-dimensional vector processing

In the long term:

• Evaluate OceanBase’s vector capabilities (rich indexes, convenient deployment)
• Continuously optimize the Milvus version (balancing cost and performance)
• Explore KV scenario optimization (Proxy + Pika)

Core principle: “One size does not fit all” + “What suits you is what’s best.”

Weibo’s DBA team believes that selecting a vector database isn’t a one-time decision but a continuously evolving process. They refine their selection by business scenario rather than replacing everything in one sweep.

Quwan Technology’s Decision Logic: One Architecture Solves Everything

Quwan Technology evaluated three solutions:

Five reasons for choosing OceanBase:

1. High compatibility: highly compatible with MySQL syntax, native SQL support for vector queries
2. Stable reliability: RTO<8s, three-replica architecture with no risk of data loss
3. HTAP capability: one engine, the same data supporting both TP and AP
4. Strong scalability: node scaling in minutes, capacity scaling in seconds
5. Multi-path fusion search over text: hybrid vector + full-text search

Quwan’s database lead admitted: compared with a solution requiring three databases to meet business needs, adopting a three-in-one database foundation reduced resource application and approval processes and dramatically cut resource consumption. What we saved wasn’t server fees but the team’s energy. When DBAs don’t have to handle Milvus etcd split-brain at 3 a.m., they can focus their daytime energy on optimizing business SQL.

IV. Future Evolution—Endgame Thoughts on Vector Databases

A Gartner 2024 report stated clearly: “73% of enterprises underestimated the long-term impact of multi-model data fusion, transactional consistency, and total cost of ownership when selecting a vector database.”

This trend is being validated:

• Early stage (2020-2022): dedicated vector databases (Milvus, Pinecone) met algorithm teams’ rapid-validation needs
• Mid stage (2023-2025): general-purpose databases began filling in vector capabilities (PostgreSQL pgvector, Redisearch)
• Future (2026+): distributed databases with native vector support become mainstream

OceanBase’s evolution path fits this trend precisely: from TP to AP and then to AI, always adhering to an “integrated” architecture.

For enterprises, we suggest considering several aspects during selection.

Suggestion one: start from business coupling, not technical hype. If vector data is tightly coupled with the core business (such as risk control or advertising), OceanBase is a must. If it’s only for algorithm-team experiments, Milvus can serve as a temporary solution.

Suggestion two: calculate the 5-year TCO, not the 1-year purchase price. Many teams look only at the server purchase price during selection—this is the biggest misconception. The true TCO includes explicit costs (hardware, cloud resources, commercial licensing fees) and implicit costs (labor, failure losses, development efficiency, and so on). Milvus’s implicit costs (labor, failures, data inconsistency) will reach 2-3 times the explicit costs over 5 years. OceanBase’s unified architecture begins showing its cost advantage as early as the second year. True cost savings come from architectural convergence, not hardware discounts.

Suggestion three: assess team capability, not the feature list. If the team has K8s experts, Milvus’s operational barrier can be lowered. Most enterprise DBAs are more familiar with the MySQL ecosystem, so OceanBase’s reuse value is greater. Don’t sacrifice the efficiency of the entire engineering team for the convenience of one team.

OceanBase’s technical team has stated many times in public forums: “We hope OceanBase can ultimately become the data foundation for AI applications, letting developers not worry about whether the underlying layer is vector search or relational query, and just focus on the business logic.” To that end, OceanBase will continue investing in vector capabilities—such as GPU-accelerated index building, support for trillion-scale vector libraries, table-level TTL and hot-cold data tiering, deep integration with LLM inference engines, and seamless collaboration with various AI ecosystem tools.

Final words: All viewpoints and data in this article come from the real practices of seven companies. The practices of these seven companies tell us: the endgame of vector search is not a hundred flowers blooming of dedicated databases, but a unified, powerful, and reliable data foundation. There is no silver bullet in technology selection—only the choice that best fits your own business scenario. If you’re also evaluating vector databases, we hope these practices can help you avoid a few detours.