Why Milvus Outperforms Traditional Databases: Deep Dive into Vector DB Architecture

Background

Information and communication technology (ICT) is undergoing a transformative wave driven by large models and generative AI (GenAI). In this context, the vector database has become a core infrastructure for GenAI, enabling efficient storage, indexing, and approximate nearest neighbor (ANN) search of high‑dimensional embedding vectors.

Understanding Vector Databases

Vector data originates from unstructured sources—images, audio, video, text—converted into multi‑dimensional vectors (typically >512 dimensions) and persisted in specialized storage. During a query, unstructured data is quantized into a vector, and the database retrieves the most similar vectors rather than exact matches.

Vector Databases vs. Traditional Databases

Traditional databases handle scalar, structured data using row‑column tables, B‑tree or hash indexes, and guarantee exact matches with ACID transactions. Vector databases, however, focus on semantic similarity search over billions of high‑dimensional vectors, where B‑tree indexes are ineffective and exact matching is impossible.

How to Choose a Vector Database

Compare databases across dimensions such as scalability, index types, performance, and ecosystem support.

Select popular indexes (HNSW for memory‑first, DiskANN for disk‑optimized) based on workload characteristics.

For high‑performance, high‑scale scenarios, Milvus, Zilliz, Vespa, and Qdrant are recommended.

Milvus in Practice at DeWu

DeWu initially deployed Milvus on Kubernetes with default HNSW indexing. The architecture required many external components (ETCD, MinIO, Pulsar) and shared storage, leading to stability issues as cluster count grew. To improve resource utilization, Milvus clusters were migrated from isolated storage pools to a shared pool, and DiskANN indexing was introduced for cost‑effective large‑scale searches.

Deployment Evolution

Early deployment used dedicated machines per cluster; later, clusters were consolidated into a shared pool, reducing idle resource usage.

Introducing Zilliz

Zilliz, a managed Milvus service, was adopted for workloads demanding sub‑90 ms latency at billion‑scale vector sizes, offering better performance and stability.

Operational Insights

Index structures and search principles: HNSW (memory‑centric) vs. DiskANN (disk‑centric).

Misconceptions: Adding more QueryNodes does not linearly improve latency due to segment‑level granularity and network variability.

Scalar indexing does not accelerate ANN searches; it can degrade performance.

Frequent small DML operations generate many delta‑logs and insert‑logs, increasing I/O overhead.

Future Outlook

Plans include building a closed‑loop data migration pipeline, enhancing data accuracy verification between upstream (e.g., MySQL) and vector stores, and further optimizing high‑availability architectures across zones and zones with mixed deployments.

Key Images