Milvus

Milvus is an open-source vector database built for billion-scale similarity search, developed by Zilliz and governed under the Linux Foundation AI & Data Foundation. First released in 2019, it is the most widely adopted open-source vector database: by December 2025 it had surpassed 40,000 GitHub stars, exceeded 100 million downloads and Docker pulls, and was used by more than 10,000 enterprise teams in production, including NVIDIA, Salesforce, eBay, Airbnb, and DoorDash ^[1][2]. Milvus is available both as self-hosted open-source software under the Apache 2.0 license and as a fully managed service through Zilliz Cloud, which advertises a 99.95% uptime SLA across 29 global regions ^[2].

History

Milvus was created by the team at Zilliz, a company founded in 2017 by Charles Xie. The initial motivation came from the growing need to search through unstructured data (images, text, audio) using vector embeddings rather than traditional keyword matching.

The project went through two major architectural generations:

• Milvus 1.x (2019-2021): A standalone vector search engine that handled small to medium-scale workloads. It was effective but limited by its monolithic architecture.
• Milvus 2.0 (2021-present): A complete rewrite with a cloud-native, distributed architecture that separates compute and storage. This redesign was necessary to support the scale and reliability requirements of production AI workloads.

Milvus joined the Linux Foundation AI & Data Foundation as an incubation project in January 2020 and graduated to top-level project status in June 2021, giving it vendor-neutral governance. Zilliz has raised approximately $113 million across multiple funding rounds. The most recent major round was a $60 million Series B-II in August 2022 ^[3]. The company relocated its headquarters from Shanghai to San Francisco as part of its push into the U.S. market.

Scroll sideways for more →

What is Milvus used for?

Milvus stores high-dimensional vector embeddings and retrieves the nearest matches to a query vector, which is the core operation behind semantic search, retrieval-augmented generation (RAG), recommendation systems, image and video search, anomaly detection, and multi-modal applications. Because it pairs approximate nearest-neighbor (ANN) search with scalar filtering, full-text search, and metadata querying in one engine, it is commonly deployed as the retrieval layer for LLM applications that need to ground responses in large private corpora.

Architecture

Milvus 2.x uses a disaggregated architecture where storage, compute, and coordination are separated into independent layers. This design allows each component to scale independently based on workload demands.

System components

The system consists of four main layers:

Scroll sideways for more →

This separation means that read-heavy workloads can scale by adding more query nodes without affecting write performance, and write-heavy workloads can scale data nodes independently. The architecture targets 99.9% uptime for production deployments ^[4].

Storage and compute separation

All persistent data in Milvus is stored in object storage (such as Amazon S3, Google Cloud Storage, or MinIO for self-hosted deployments). The compute nodes are stateless and pull data from storage as needed. A message queue (Apache Kafka or Apache Pulsar) serves as the log backbone, capturing all data mutations in an ordered stream that compute nodes can replay.

This architecture has several practical benefits: compute nodes can be restarted or replaced without data loss, storage costs scale independently of compute costs, and different regions can share the same underlying data.

Stateless microservices on Kubernetes

All Milvus worker nodes are designed as stateless microservices deployed on Kubernetes. This design enables quick recovery from failures: if a query node crashes, Kubernetes automatically restarts it, and the node re-attaches to the shared object storage without data loss. The stateless design also enables auto-scaling, where the number of query or data nodes adjusts based on current load.

Component interaction

The flow of a typical write operation illustrates how the components work together:

1. A client sends an insert request to a proxy node.
2. The proxy validates the request and forwards it to the data coordinator.
3. The data coordinator assigns the data to a data node and writes it to the message queue.
4. The data node consumes from the message queue, writes data to object storage, and notifies the coordinator.
5. The index coordinator detects new data and assigns index building to an index node.
6. The index node builds the index and writes it to object storage.
7. The query coordinator notifies query nodes to load the new segment for search.

For read operations, the query coordinator routes requests to query nodes that have the relevant data segments loaded in memory. If a search spans multiple segments or partitions, results are gathered from multiple query nodes and merged before returning to the client.

Index types

Milvus supports a wide range of indexing algorithms, more than most competing vector databases. The choice of index involves tradeoffs between search speed, recall accuracy, memory usage, and build time.

Scroll sideways for more →

How do you choose a Milvus index type?

The choice of index type depends on the workload characteristics:

Scroll sideways for more →

The DiskANN index is particularly significant for cost-sensitive deployments. It allows Milvus to search over datasets that do not fit in memory by keeping the graph structure on SSD, trading some latency for dramatically lower hardware costs.

GPU acceleration

Milvus provides GPU-accelerated index building and search through NVIDIA's cuVS library, which includes the CAGRA (Cuda-Accelerated Graph index for Approximate nearest neighbor) algorithm. GPU acceleration is most beneficial for:

• Building indexes on large datasets, where the parallel processing power of GPUs can reduce build times by an order of magnitude.
• High-throughput batch search scenarios, where many queries are processed simultaneously.
• Real-time search at very low latency, where GPU memory bandwidth enables faster distance calculations than CPU.

GPU indexes require NVIDIA GPUs with CUDA support. For deployments without GPUs, CPU-based indexes like HNSW and DiskANN remain strong options ^[5].

GPU index parameters

Scroll sideways for more →

Key features

Hybrid search and full-text search

Milvus 2.5, released in December 2024, introduced native full-text search using BM25 scoring. The implementation converts text into sparse vectors representing BM25 scores, and users can input raw text directly with Milvus handling the sparse embedding generation automatically. This eliminates the need for a separate keyword search system ^[6].

Hybrid search in Milvus works through its multi-vector architecture. A single collection can have up to 10 vector fields, and searches can run across multiple vector columns simultaneously. Results from different vector fields are combined using configurable fusion strategies:

Scroll sideways for more →

This supports several hybrid search patterns:

• Dense + sparse vector search (semantic + keyword)
• Dense + full-text search
• Multi-modal search (text embedding + image embedding)

Milvus claims that its hybrid search processes queries 30 times faster than traditional solutions that require separate vector and keyword search systems ^[6]. In Milvus 2.6, Zilliz reports that the enhanced BM25 full-text engine delivers 3-4x higher throughput than Elasticsearch at equivalent recall, reaching up to 7x higher QPS on specific workloads ^[7].

Zilliz Cloud further enhances full-text search with JSON Shredding and JSON Path indexing, which accelerate metadata filtering by up to 100x. Benchmarks show that Zilliz Cloud's full-text search delivers up to 7x faster performance than Elasticsearch on selected datasets ^[8]. In Milvus 2.6, the new JSON Path Index reduced an example filter latency from 140ms to 1.5ms, a roughly 99% reduction ^[7].

Multi-vector search

Beyond hybrid search, Milvus supports storing and searching across multiple vector fields per record. This is useful for multi-modal applications. For example, a product catalog might store separate embeddings for the product title, description, and image. A search can query across all three vector fields and combine the results, weighting each field based on its relevance to the use case.

Billion-scale operation

Milvus is regularly deployed at hundreds of millions to billions of vectors in production. The distributed architecture allows horizontal scaling: adding more query nodes increases read throughput, and adding data nodes increases write throughput. Sharding distributes collections across nodes, and partitioning within collections allows users to scope searches to specific data subsets.

What is new in Milvus 2.6?

Milvus 2.6, released in June 2025, was positioned by Zilliz as a cost-reduction release for billion-scale vector search. Its headline additions are RaBitQ 1-bit quantization, the Woodpecker write-ahead log, and tiered storage.

• RaBitQ 1-bit quantization (IVF_RABITQ). The new index compresses the main index to 1/32 of its original size through 1-bit quantization, and when combined with optional SQ8 refinement it maintains 94.9% recall while cutting the memory footprint by 72% and delivering roughly 4x faster queries than IVF_FLAT ^[7].
• Woodpecker WAL. Woodpecker is a purpose-built, cloud-native write-ahead log with a zero-disk design that persists all log data directly in object storage (S3, Google Cloud Storage, or MinIO), removing the external Kafka or Pulsar dependency. In S3 mode it reaches about 750 MB/s, which Zilliz reports as 5.8x higher throughput than Kafka and 7x higher than Pulsar; local file system mode reaches 450 MB/s, about 3.5x faster than Kafka ^[7].
• Tiered storage. Intelligent tiered storage moves cold data to cheaper layers, which Zilliz reports cuts costs by up to 50% ^[7].

James Luan, VP of Engineering at Zilliz, framed the design priorities around production economics: "Teams depend on Milvus in demanding environments where performance, reliability, and cost all matter." ^[1]

Partition management

Milvus provides two approaches to partitioning data within collections:

Traditional partitions

Users can manually create named partitions within a collection and assign data to specific partitions during insert. Searches can then be scoped to one or more partitions, reducing the amount of data scanned:

from pymilvus import Collection

collection = Collection("products")

# Create partitions
collection.create_partition("electronics")
collection.create_partition("clothing")

# Insert into a specific partition
collection.insert(data, partition_name="electronics")

# Search within a specific partition
results = collection.search(
    data=query_vectors,
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    limit=10,
    partition_names=["electronics"]
)

Partition keys

Partition keys provide an automatic approach to partitioning. Instead of manually assigning data to partitions, users designate a scalar field as the partition key. Milvus automatically routes data to the appropriate partition based on the field's value. This is particularly useful for multi-tenant applications, where a tenant ID field can serve as the partition key ^[9].

Milvus 2.5.5 improved partition scalability, making it feasible to run a single cluster with 10,000 collections and 100,000 partitions ^[9].

Consistency levels

Milvus supports multiple consistency levels for search operations, allowing users to trade consistency for performance:

Scroll sideways for more →

Bounded staleness is the default consistency level, providing a balance between data freshness and query performance. The staleness window is configurable, typically set to a few seconds ^[10].

Zilliz Cloud

Zilliz Cloud is the fully managed service built on Milvus, offered in three tiers. It runs across 29 global regions on AWS, Azure, and Google Cloud, advertises a 99.95% uptime SLA, and is SOC 2 Type II compliant ^[2].

Scroll sideways for more →

Zilliz Cloud runs on Cardinal, a proprietary vector search engine that Zilliz describes as delivering up to 10x faster performance than open-source Milvus. Cardinal includes additional optimizations for cloud deployment, including more aggressive query planning and caching ^[11].

How does Zilliz Cloud differ from open-source Milvus?

Scroll sideways for more →

How does Milvus compare with Pinecone, Qdrant, Weaviate, and pgvector?

Scroll sideways for more →

Milvus's primary advantage over competitors is its combination of scale and feature breadth. It supports more index types than any other vector database and can handle larger datasets than most alternatives. The tradeoff is operational complexity: a full Milvus deployment involves multiple components (coordinators, workers, message queue, object storage), which is substantially more complex than running a single Qdrant binary or enabling pgvector on an existing PostgreSQL instance.

For teams without dedicated infrastructure engineers, Zilliz Cloud or a simpler alternative like Qdrant or pgvector may be more practical. For teams operating at massive scale with existing Kubernetes infrastructure, Milvus provides capabilities that simpler systems cannot match ^[12].

Integration ecosystem

Milvus provides SDKs for Python, Java, Go, Node.js, and C#. It integrates with the major LLM orchestration frameworks:

Scroll sideways for more →

Milvus also integrates with data pipeline tools like Apache Spark, Apache Flink, and Airbyte for bulk data ingestion from existing data sources.

Attu management UI

Attu is an open-source graphical management tool for Milvus. It provides a web-based interface for managing collections, viewing data, running queries, monitoring system health, and managing indexes. Attu is particularly useful for teams that prefer visual tools over CLI or SDK-based management.

Performance at scale

Milvus publishes performance benchmarks across multiple real-world datasets, measuring throughput, latency, and recall rate.

Key benchmark results include ^[13]:

Scroll sideways for more →

Zilliz Cloud (running Cardinal) benchmarks show:

• Sub-10ms latency on billion-scale datasets with auto-scaling
• 7x faster full-text search than Elasticsearch on selected datasets
• Up to 100x faster metadata filtering with JSON Shredding ^[8]

In scaled-out deployments, Milvus shows little performance degradation in search latency and QPS as the cluster grows, demonstrating near-linear scalability when using multiple replicas ^[13].

Is Milvus open source?

Yes. Milvus is distributed under the Apache 2.0 license and is governed as a top-level project of the Linux Foundation AI & Data Foundation, with Zilliz as its primary contributor ^[2]. The full source, including the distributed engine and index implementations, is hosted at github.com/milvus-io/milvus. Zilliz Cloud is the commercial managed offering and uses a proprietary engine (Cardinal), but the core Milvus database remains fully open source.

Current state

Milvus continues to release frequently, with version 2.6 adding RaBitQ quantization, the Woodpecker WAL, tiered storage, and improvements to multilingual full-text search. The project's position within the LF AI & Data Foundation provides governance stability and signals enterprise readiness.

Recent releases have focused on security, with Milvus 2.5.27 and 2.6.10 addressing CVE-2026-26190, an authentication bypass vulnerability on the metrics port. Version 2.6.10 also introduced automatic FP32-to-FP16/BF16 conversion for reduced storage and optimized segment loading ^[14].

The vector database market has become increasingly competitive, with Pinecone, Qdrant, Weaviate, and pgvector all improving rapidly. Milvus differentiates itself primarily through its scale capabilities (tested and deployed at billions of vectors), its breadth of index types (ten or more), and its GPU acceleration support. For organizations building AI applications that need to search across very large vector datasets with low latency, Milvus remains one of the strongest options available.

References

1. PR Newswire. Milvus Surpasses 40,000 GitHub Stars, Reinforcing Leadership in Open-Source Vector Databases. December 2025. ↩
2. Zilliz. Milvus | Open-source Vector Database created by Zilliz ↩
3. TechCrunch. Zilliz raises $60M for open-source Milvus vector database. August 2022. ↩
4. Milvus Documentation. What is Milvus ↩
5. Zilliz. What is Milvus ↩
6. Milvus Blog. Introducing Milvus 2.5: Full-Text Search, More Powerful Metadata Filtering, and Usability Improvements. December 2024. ↩
7. Milvus Blog. Introducing Milvus 2.6: Affordable Vector Search at Billion Scale. June 2025. ↩
8. PR Newswire. Zilliz Announces General Availability of Milvus 2.6.x on Zilliz Cloud ↩
9. Milvus Documentation. Use Partition Key ↩
10. Milvus Documentation. Consistency ↩
11. Zilliz Cloud. Managed vector database built on Milvus ↩
12. TensorBlue. Vector Database Comparison 2025: Pinecone vs Weaviate vs Qdrant vs Milvus vs FAISS ↩
13. Zilliz. Milvus Performance Report ↩
14. GitHub. Milvus Release Notes ↩
15. Milvus Documentation. Milvus Architecture Overview