# Milvus

Milvus is an open-source, distributed vector database built for billions of vectors, with many index types, GPU acceleration and hybrid search. Learn its architecture.

## Overview

Milvus is an open-source vector database designed to store and search very large collections of [embeddings](/tools/embeddings), from a few thousand vectors on a laptop up to billions across a cluster. It is developed mainly by the company Zilliz, is a graduated project of the LF AI & Data Foundation, and is released under the Apache 2.0 licence. It is written mostly in Go and C++, with official SDKs for Python, Java, Go and Node.js.

Milvus stands out for scale and choice. It separates storage from compute so each can grow on its own, and it offers many index types: graph indexes such as [HNSW](/tools/hnsw), cluster-based indexes such as IVF and [IVF-PQ](/tools/ivf-pq), disk-based [DiskANN](/tools/diskann), and GPU indexes. You can pick the trade-off between memory, speed and accuracy that suits each collection. It also supports scalar filtering, sparse vectors and [hybrid search](/tools/hybrid-search).

Think of a national parcel network. A single post office works well for a village, but a country needs sorting hubs, warehouses, vans and a central tracking system, each scaled separately. Milvus is built like that network: separate parts handle incoming data, storage, indexing and queries, so the whole system can grow to very large volumes.

## What it is

| Part | Role |
|---|---|
| Collection | A named set of entities with a schema, similar to a table |
| Schema and fields | Defines the primary key, vector fields and scalar fields |
| Partition | A subdivision of a collection, often by date or tenant |
| Segment | The unit in which data is stored, indexed and loaded |
| Index | A structure for fast search on a vector or scalar field |
| Access layer | Proxies that receive client requests and route them |
| Coordinator | Manages metadata, scheduling and cluster state |
| Worker nodes | Handle queries, data writes and index building |
| Storage layer | Metadata store, a write log and object storage such as [Amazon S3](/tools/amazon-s3) |

Milvus can be deployed in several ways: Milvus Lite, a lightweight library for Python prototypes; a standalone server; or a distributed cluster on [Kubernetes](/tools/kubernetes). Zilliz also offers a managed service, Zilliz Cloud.

## Where it came from

Zilliz began work on Milvus in 2017, and the first open-source release came in October 2019. In January 2020 the project joined the Linux Foundation's AI umbrella as an incubation project, and in June 2021 it graduated under the LF AI & Data Foundation.

Early versions were single-node systems built around similarity search libraries. Milvus 2.0, released in January 2022, was a major redesign: a cloud-native, distributed architecture with separate storage and compute, a log-based write path and independently scalable worker nodes. Later 2.x releases added features such as dynamic schemas, partition keys for multi-tenancy, sparse vectors, full-text search with [BM25](/tools/bm25), hybrid search across several vector fields, GPU indexing through NVIDIA's cuVS library including the CAGRA graph index, and further work on cost and streaming. Its search engine builds on modified forks of well-known libraries, including [FAISS](/tools/faiss), DiskANN and hnswlib. A 3.0 version was in preview in 2026; check the official release notes for its current status.

## How it works

### Step 1: Define a schema

You create a collection with a primary key, one or more vector fields with a fixed dimension, and scalar fields such as category, date or tenant ID. A dynamic field option allows extra keys without changing the schema.

### Step 2: Write data

Inserts go through a proxy to a write-ahead log. This log is the source of truth for new data and allows recovery and replication. Data is grouped into growing segments in memory.

### Step 3: Seal and persist

When a segment reaches a size or time limit it is sealed and written to object storage as immutable files. Metadata about segments is kept in a metadata store.

### Step 4: Build indexes

Index nodes build the chosen index for each sealed segment. Options include:

- FLAT: exact search, slow but perfect recall.
- IVF_FLAT and IVF_PQ: cluster vectors and search only nearby clusters, with optional compression.
- HNSW: a graph index with high recall and speed, but more memory.
- DISKANN: keeps most of the index on SSD for large datasets with limited memory.
- GPU indexes such as GPU_CAGRA: build and search on GPUs for high throughput.
- Sparse and scalar indexes for keyword-style vectors and filters.

### Step 5: Load and query

Query nodes load segments and indexes into memory or map them from disk. A search request is split across segments, each returns its best candidates, and results are merged. Filters on scalar fields are applied during search. Consistency levels let you choose between seeing the newest writes and getting faster responses.

A short example using the Python client with Milvus Lite:

```python
from pymilvus import MilvusClient

client = MilvusClient("demo.db")
client.create_collection(collection_name="docs", dimension=768)
client.insert(collection_name="docs", data=[{"id": 1, "vector": vec, "lang": "en"}])
hits = client.search(collection_name="docs", data=[query_vec], limit=5, filter='lang == "en"')
```

### Step 6: Scale

Because storage and compute are separate, you can add query nodes for more search traffic or data nodes for more writes without moving all the data.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Collection | Top-level container for entities with one schema |
| Entity | One row: primary key, vectors and scalar fields |
| Segment | A chunk of data that is indexed and loaded as a unit |
| Partition key | A field that automatically spreads data into partitions, useful for tenants |
| Metric type | Distance measure, such as L2, inner product or cosine |
| nlist and nprobe | For IVF indexes, number of clusters and how many to search |
| M and efConstruction | HNSW graph settings for links per node and build quality |
| Consistency level | How fresh the data seen by a query must be |
| Hybrid search | Searching several vector fields and fusing results |
| Milvus Lite | An embedded version for local development |

## A worked example

An illustrative online marketplace wants image-based "find similar products" over 400 million product images.

1. Each image is encoded into a 512-dimensional vector. At 4 bytes per value, raw vectors need about 400 million × 2 KB, roughly 820 GB.
2. Keeping full HNSW in memory would need well over that, so the team tests two options on a 10-million sample.
3. IVF_PQ with nlist of 65,536 and strong compression fits in about one tenth of the raw size. With nprobe of 64, recall at 10 is about 0.90 in their test.
4. DISKANN keeps most data on SSD with a small in-memory part, reaching recall at 10 of about 0.95 at a few milliseconds more latency.
5. They choose DISKANN for the main collection and add a partition key on product category, so filtered queries touch less data.
6. The cluster runs on Kubernetes with several query nodes. Peak traffic of 3,000 queries per second is met by adding query nodes, without reloading all data.
7. New products are inserted continuously and become searchable within seconds under the bounded consistency level.

All figures are illustrative. The point is that Milvus lets the team choose an index per collection to balance memory, cost and recall at this scale.

## Strengths and limitations

**Strengths:**

- Designed for very large datasets, into billions of vectors.
- Wide choice of index types, including disk-based and GPU indexes.
- Storage and compute scale independently.
- Supports dense, sparse and multi-vector hybrid search with filtering.
- Open source under Apache 2.0, with a managed option.
- Runs from a single Python file to a large cluster with similar APIs.

**Limitations:**

- A distributed cluster has many components to operate and monitor.
- Index tuning needs care, and defaults may not fit every workload.
- Higher overhead than simpler tools for small datasets.
- Data must be loaded into query nodes before searching, which takes time for big collections.
- Rapid development means features and configuration differ across versions.

## How it compares with alternatives

| System | Scale focus | Notable features | Consider when |
|---|---|---|---|
| Milvus | Very large, distributed | Many index types, GPU, separate storage and compute | Hundreds of millions to billions of vectors |
| [Qdrant](/tools/qdrant) | Small to large | Rust engine, payload filtering, quantisation | Filter-heavy production search |
| Weaviate | Small to large | Modules, built-in hybrid, multi-tenancy | Feature-rich search with model integrations |
| pgvector | Small to medium | SQL and vectors together | You already use PostgreSQL |
| [FAISS](/tools/faiss) | Any, as a library | Fast indexes, no database features | Custom pipelines and research |

## Practical guidance and best practices

1. Prototype with Milvus Lite or standalone, then move to a cluster only when scale requires it.
2. Choose indexes per collection based on measured recall, latency and memory.
3. Benchmark on a realistic sample with your real filters, not on random vectors.
4. Use partition keys for multi-tenant or naturally divided data.
5. Pick the consistency level your application really needs; stronger levels cost latency.
6. Monitor memory, segment counts and index build progress.
7. Store vectors normalised and use the matching metric type.
8. Read release notes before upgrading, especially across major versions.

## Common mistakes

- Running a full distributed cluster for a few hundred thousand vectors.
- Choosing HNSW for everything and running out of memory at scale.
- Forgetting to load a collection before searching it.
- Setting nprobe or ef too low and accepting poor recall without measuring.
- Using strong consistency everywhere and blaming the system for slow queries.
- Defining schemas without the scalar fields needed for filtering later.

## Frequently asked questions

### Is Milvus free?

Yes. Milvus is open source under the Apache 2.0 licence. Zilliz Cloud, the managed service from the main developer, is paid.

### What is the relationship between Milvus and Zilliz?

Zilliz created Milvus and remains its main contributor. The project itself is governed under the LF AI & Data Foundation, where it is a graduated project.

### Which index should I start with?

For moderate data that fits in memory, HNSW is a common default. For very large data with limited memory, consider IVF_PQ or DISKANN. For high-throughput GPU servers, consider GPU indexes. Measure recall and latency on your data.

### Can Milvus do keyword search?

Recent versions support sparse vectors and full-text search with BM25, which can be combined with dense vectors in hybrid search.

### How does Milvus handle multi-tenancy?

Options include separate collections, partitions or a partition key that routes each tenant's data automatically. The right choice depends on the number of tenants and isolation needs.

### Do I need Kubernetes?

Only for the distributed deployment. Milvus Lite runs inside Python, and the standalone server runs in a single container.

## Glossary

- Vector database: a database built to store and search embeddings.
- Approximate nearest neighbour: fast search that may miss a few true matches.
- Object storage: durable file storage such as S3.
- Write-ahead log: a log of changes written before they are applied.
- Recall: share of true nearest neighbours returned.
- Quantisation: compressing vectors to use less memory.
- Shard: a horizontal partition of data across nodes.
- GPU index: an index built and searched on graphics processors.

## Summary

Milvus is an open-source, distributed vector database created by Zilliz, first released in 2019 and a graduated LF AI & Data project since 2021. Its cloud-native design, introduced with Milvus 2.0 in 2022, separates storage and compute and supports many index types, including HNSW, IVF variants, DiskANN and GPU indexes, plus filtering, sparse vectors and hybrid search. It is a strong choice for very large vector workloads, provided teams invest in index tuning and cluster operations, and it scales down to Milvus Lite for local development.