Chroma

• CategoryEmbedded
• EnginePython / Rust core
• PricingOpen source
• LicenseApache-2.0
• Created2022
• GitHub stars22.4k
• Hybrid searchNo
• Edge-readyNo
• Multi-tenantSingle-tenant
• Max dimensionsunlimited

Chroma runs in-process, like SQLite for vectors. Python-first SDK, simple API, optional client-server mode for production. The default vector DB for prototype RAG apps and LangChain / LlamaIndex tutorials. Distinct from purpose-built engines: Chroma is for the hobbyist-to-mid-scale tier, not for big production workloads.

• Prototype RAG apps where adding any infrastructure is overhead
• Single-tenant Python tools embedded in another app
• Small to mid-scale workloads under ~5M vectors

Skip Chroma for high-traffic production workloads, it does not yet match Pinecone or Qdrant on latency and throughput at scale. Skip for non-Python stacks; the Python SDK is the path of least resistance.

Chroma is the right pick for prototypes and Python tools. For serious RAG production, graduate to pgvector (if Postgres-aligned) or Qdrant (if not).

Chroma's design point is that adding a vector store should not mean adding a service. It runs inside your Python process, persists to a local directory, and gets you from raw text to a working retrieval loop in a handful of lines, with a default embedding function so you do not have to pick a model on day one. There is a client-server mode and a hosted option when you outgrow in-process, but the embedded path is the one the ergonomics were designed around and it shows. It is single-tenant in practice too. Collections give you logical separation, but not the per-tenant isolation primitives Weaviate and Qdrant expose, so a multi-customer application ends up enforcing that boundary in application code and paying the filtering cost that implies.

Two things tend to bite. The first is the lack of native keyword search, so hybrid retrieval, which is usually what fixes a RAG pipeline that misses exact names, product codes, and error strings, has to be assembled outside the database. pgvector, Weaviate, and Qdrant all give you that in one query. The second is throughput: Chroma is comfortable in the small-to-mid range the project targets and does not pretend to match Qdrant or Pinecone under sustained concurrent load. The migration out is easy, which is rather the point. You hold the documents and the embedding model, so re-ingesting into pgvector or Qdrant is a script rather than a project. Treat Chroma as a stage rather than a destination and it is an excellent tool.

• Official homepage →
• GitHub repo →

The 30-min call is where your vector-DB choice becomes a real RAG architecture, a chunking + reranking strategy that actually works for your corpus, and a price range you can take to your stakeholders. Describe your data shape, your query patterns, your latency budget. I tell you whether Chroma is genuinely your fit.