Chroma vs Milvus
Both are catalogued under Vector & Storage. The figures come from the GitHub API; the assessments are ours.
At a glance
| At a glance | Chroma | Milvus |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Languages | Rust, Python | Go, C++ |
| Deployment | Runs locally / Self-hosted / Managed cloud | Self-hosted / Managed cloud |
| Maturity | Established | Established |
| Stars | 29.1k | 45.6k |
| Star growth over the last 7 days | −2 ★ | +1 ★ |
| Forks | 2.4k | 4.2k |
| Open issues | 793 | 1.3k |
| Last commit | 15 Aug 2026 | 15 Aug 2026 |
| Activity | Active | Active |
What each one does
Chroma
The lowest-friction way to get retrieval working: no server to stand up, no cluster to size. That makes it excellent for prototypes and small production loads, and the point at which you outgrow it is a real consideration to plan for rather than discover.
Full entry →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 →What you can do
Chroma
- Get retrieval running in one file —
chromadb.Client()creates an in-memory store andcollection.add()handles tokenization, embedding and indexing, so no embedding model is wired up by hand. - Filter alongside the vector search —
collection.query()takeswherefor metadata equality andwhere_documentwith$containsfor substring matching in the same call as the similarity search. - Move to client-server mode —
chroma run --path /chroma_db_pathstarts a server against the same four-function API once a single embedded process is no longer enough. - Query from Python or JavaScript — The Python client comes from
pip install chromadband the JavaScript one fromnpm install chromadb; pointed at the samechroma runserver, both work on one set of collections, so the job that writes and the service that queries need not share a language.
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.