Milvus

Last reviewed Aug 26, 2026 · 897 words

Milvus earns its 4 GB minimum and its "Hard" difficulty rating only when you have tens of millions of vectors or need to serve searches across several machines. Below that, Milvus Lite (the same engine as a Python library writing to a single file) or a single-binary database like Qdrant gets you the same recall with one process instead of three. I run Milvus standalone for one workload and would not reach for it again for anything that fits in the RAM of one box.

Three products share one name, and it changes the whole install

Milvus ships in three modes, and picking the wrong one is the most common mistake I see.

Milvus Lite is pip install pymilvus and then MilvusClient("./milvus.db"). No server, no Docker, vectors stored in a local file. It exposes the same client API as the server, so code written against it moves to a full deployment unchanged. For prototyping a RAG pipeline or anything under a few million vectors on a laptop, this is the whole answer.

Milvus Standalone is the Docker deployment, and it is not one container. The official compose file runs three: the Milvus server itself, etcd for metadata, and MinIO for object storage. That is the honest minimum, and it is why the catalogue lists 4 GB rather than the few hundred megabytes a Qdrant container idles at. The Milvus process listens on 19530 (gRPC, the port every SDK talks to) and 9091 (HTTP, metrics, and /healthz).

Milvus Distributed is the Kubernetes deployment via Helm: separate query nodes, data nodes, index nodes, coordinators, a proxy tier, plus Pulsar or Kafka as a message log alongside etcd and S3-compatible storage. That is where "billion-scale" comes from and also where "complex distributed deployment" comes from. I would not run it without a Kubernetes cluster you already operate for other reasons.

The vectors must fit in RAM, and the index adds more

The raw column is arithmetic (768 dimensions times 4 bytes) and is exact; the index column is an estimate from experience and depends on the HNSW M parameter. The critical operational fact: a Milvus collection must be explicitly loaded into memory before it can be searched, and a load that does not fit fails or swaps. Milvus offers a real choice of index types (FLAT for exact search, IVF_FLAT and IVF_SQ8 for memory-conscious approximate search, HNSW for the best speed-recall tradeoff, DiskANN for datasets larger than RAM) and switching between them means rebuilding the index, not flipping a flag. Read the choosing a vector database post before committing to a dimension count; 1,536-dim embeddings double every number in the table above.

Hybrid search is the feature that justifies the complexity

The strongest technical argument for Milvus over smaller databases is hybrid search: a single query that combines dense vectors (semantic similarity) with sparse vectors (BM25-style keyword matching) and fuses the rankings. Recent Milvus releases can generate the sparse side themselves from a text field, which means you get keyword search and semantic search over the same collection without running Elasticsearch next to it. For production retrieval that was the difference between "usually finds it" and "finds the document with the exact product code in it". The embeddings in production post goes into why pure dense retrieval disappoints on exact-match queries.

Milvus also supports scalar filtering on metadata fields, partitions and partition keys for multi-tenant collections, and multiple vector fields per row, so one record can carry a text embedding and an image embedding and be searched by either.

Operating standalone: what actually breaks

Backups are the weak spot. Data lives across MinIO and etcd, so a naive volume copy of one container is useless; use the official milvus-backup tool or snapshot all three volumes together with Milvus stopped. Upgrades between minor versions have been clean for me, but read the release notes, because index formats occasionally change and trigger a rebuild. Install Attu, the official web GUI, from day one; it lets you inspect collections, run test queries, and see whether a collection is loaded, which is otherwise a mystery solved only through the SDK. And put a Prometheus scrape on port 9091: query latency and memory per collection are the two numbers you will want when something slows down.

What I'd do

Start on Milvus Lite and build the application against it. Move to Standalone (the three-container compose from the docs, on a box with at least 8 GB free, HNSW index, Attu alongside) only when the vector count is heading past a few million or when more than one service needs to query it. Reach for Distributed only on an existing Kubernetes cluster with a team to run it. If your dataset will never exceed 10 million vectors and you have no hybrid-search need, run Qdrant instead and spend the saved 3 GB on a bigger embedding model.