Milvus vs Qdrant
Both are catalogued under Vector & Storage. The figures come from the GitHub API; the assessments are ours.
MilvusDistributed vector database built for very large collectionsOfficialApache-2.0
QdrantVector database with first-class payload filteringOfficialApache-2.0At a glance
| At a glance | Milvus | Qdrant |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Languages | Go, C++ | Rust |
| Deployment | Self-hosted / Managed cloud | Self-hosted / Runs locally / Managed cloud |
| Maturity | Established | Established |
| Stars | 45.6k | 34k |
| Star growth over the last 7 days | +1 ★ | +1 ★ |
| Forks | 4.2k | 2.6k |
| Open issues | 1.3k | 699 |
| Last commit | 15 Aug 2026 | 15 Aug 2026 |
| Activity | Active | Active |
What each one does
Milvus
Separates storage from compute so indexing and querying scale independently — the architecture you want at billions of vectors. That capability comes with operational weight; below a few million vectors, something simpler will serve you better.
Full entry →Qdrant
Written in Rust and built so that metadata filters apply during search rather than after it — the difference that keeps results correct when an agent queries a narrow slice of a large collection. Runs from a single container for local development up to a distributed cluster.
Full entry →What you can do
Milvus
- Prototype without running a server — pymilvus[milvus-lite] lets MilvusClient persist to a local file, and the same client code reaches a self-hosted cluster or Zilliz Cloud by swapping uri and token.
- Mix full-text and vector search — Sparse and dense vectors sit in one collection, so BM25 full-text search and learned sparse embeddings such as SPLADE and BGE-M3 can be fused with dense results through a rerank function.
- Choose an index per workload — HNSW, IVF, FLAT, SCANN and DiskANN are all available, along with quantization variants such as IVFPQ, mmap for memory pressure, and GPU indexing via NVIDIA CAGRA.
- Scale reads and writes separately — The distributed architecture splits compute from storage, so read-heavy traffic is served by adding query nodes and write-heavy ingestion by adding data nodes, with replicas for fault tolerance.
- Isolate tenants in one cluster — Isolation can be set at database, collection, partition or partition-key level, combined with RBAC, TLS and hot/cold storage tiers to keep frequently accessed data in memory or on SSD.
Qdrant
- Filter without losing recall — Payload conditions are applied inside the vector search itself rather than as a post-filter over the returned results, and a filter combines keyword, full-text, numeric-range and geo conditions under
must,shouldandmust_not. - Start from a single container —
docker run -p 6333:6333 qdrant/qdrantis the whole local setup, and the README flags that this default has no authentication and is open on every interface; production scales out with sharding and replication, resizing collections with no downtime. - Combine dense and sparse in one query — Dense vectors, sparse vectors and multivectors for late-interaction models such as ColBERT can be queried together, with the result lists merged by Reciprocal Rank Fusion or Distribution-Based Score Fusion.
- Connect from six official clients — Official clients exist for Python (
qdrant-client), JavaScript/TypeScript (@qdrant/js-client-rest), Go, Rust, .NET/C# and Java, over a REST API with an OpenAPI 3.0 spec plus a gRPC interface for production-tier traffic. - Cut RAM before adding nodes — Built-in quantization reduces RAM usage by up to 97% and lets you tune the trade-off between search speed and precision, with on-disk storage for the vectors that need not stay in memory.