Chroma vs Qdrant
Both are catalogued under Vector & Storage. The figures come from the GitHub API; the assessments are ours.
At a glance
| At a glance | Chroma | Qdrant |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Languages | Rust, Python | Rust |
| Deployment | Runs locally / Self-hosted / Managed cloud | Self-hosted / Runs locally / Managed cloud |
| Maturity | Established | Established |
| Stars | 29.1k | 34k |
| Star growth over the last 7 days | −2 ★ | +1 ★ |
| Forks | 2.4k | 2.6k |
| Open issues | 793 | 699 |
| 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 →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
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.
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.