Chroma

Chroma is an open-source embedding database built for AI application developers who need to store and retrieve vector embeddings without infrastructure overhead. Founded in San Francisco in April 2022 by Jeff Huber (CEO) and Anton Troynikov (CTO), the company raised an $18M seed round in April 2023 and has built one of the most widely-cited vector databases in the developer community, with 27.7k GitHub stars as of April 2026. The core is Apache 2.0 licensed, installable with a single pip install chromadb, and requires no separate server to run in development mode.

The API consists of four primary operations: create a collection, add embeddings, query, and delete. That deliberate minimalism covers most RAG prototype needs. Beyond the basic API, Chroma supports dense vector similarity search, full-text search, sparse vector retrieval (BM25 and SPLADE, added November 2025), metadata filtering, and regex search. The 2025 Rust core rewrite delivered 3-5x faster writes and queries with true multithreading. Chroma Cloud, the managed hosted version, launched to general availability in August 2025 with serverless pricing, SOC 2 Type II compliance, and data tiering across memory cache, SSD, and object storage.

What Chroma actually does in April 2026

Chroma runs in three modes depending on where you are in a project. In embedded mode, it runs inside your Python or JavaScript process with no network hop and zero config. In client-server mode, chroma run starts a local HTTP server you can hit from any language with an official SDK. Chroma Cloud provides the managed version with automatic scaling and $5 free credits on the Starter plan.

Current release (v1.5.8, April 16, 2026) supports collections as the primary organizational unit. Each collection holds embeddings alongside their source documents and arbitrary metadata. Queries can be by embedding vector, by document text (auto-embedded), by metadata filter, or any combination. The November 2025 addition of sparse vector search means hybrid retrieval (dense + keyword) is now first-class rather than a workaround.

The 2025 Rust core rewrite was Chroma's most significant technical milestone. The original Python implementation was constrained by the Global Interpreter Lock, blocking true parallelism. The Rust rewrite eliminated that bottleneck and delivered measured 3-5x improvements for writes and queries on 1M OpenAI 1536-dimensional embeddings. Native bindings for JavaScript, Ruby, and Swift were added alongside, meaning Chroma is no longer a Python-first tool. WASM-powered browser deployments are also available via the JS bindings.

Chroma Sync, added in late 2025, handles automated ingestion from GitHub repositories, S3 buckets, and web pages: crawling, chunking, embedding, and indexing without manual pipeline management. This is aimed at teams who want a managed data layer for RAG, not just a storage backend.

Where Chroma sits versus Qdrant and pgvector

Three tools dominate developer conversations about where to put embeddings: Chroma, Qdrant, and pgvector. They occupy meaningfully different positions.

Qdrant is written in Rust from the ground up (not a rewrite, native from day one) and was designed specifically for production-scale filtered vector search. Its HNSW indexing with payload filtering lets you combine similarity matching and metadata constraints (numeric ranges, text matches, geographic coordinates) while holding sub-5ms query times at scale. Qdrant supports distributed multi-node clustering as a first-class feature and handles billion-scale vector workloads in production. Chroma's Rust rewrite narrows the raw performance gap, but Qdrant's distributed architecture is structural. A Chroma collection is fundamentally single-node. Qdrant clusters are not.

pgvector is a PostgreSQL extension, not a standalone database. Vectors, documents, and application data share the same table, the same transaction, and the same SQL queries. Teams already running Postgres (the majority of backend stacks) add pgvector without new credentials, sync pipelines, or infrastructure to monitor. pgvector scales comfortably to 5M vectors on a standard Postgres instance and provides ACID guarantees by default. The tradeoff: pgvector has no embedded in-memory mode, requires a running Postgres server even in development, and lacks Chroma's Python-native API for teams not already fluent in SQL.

The practical decision tree most teams land on: use Chroma for local development and prototypes, evaluate pgvector if your backend already runs Postgres, and move to Qdrant (or Weaviate, Pinecone) if you need production distribution or billion-scale indexing. Chroma's community cookbook has a literal "Road to Production" guide that openly recommends considering alternatives at scale, which is unusually honest for a vendor's own documentation.

"ChromaDB is generally a decent option if you have strong hardware and need to build a prototype quickly. But if you're planning to go into production, it makes sense to move to more mature solutions." - Olexander Hryhor, Solutions Architect at AltexSoft, 2025

What the daily development workflow looks like

The typical Chroma workflow begins at a terminal. Install, import, create a client, create a collection, add documents with their embeddings, query by text. A working RAG retrieval pipeline is achievable in five to ten lines of Python, often inside fifteen minutes on a fresh machine. There is no server to start in embedded mode, no API key to configure, and no schema to define upfront.

LangChain and LlamaIndex both treat Chroma as a first-class integration. Setting Chroma as a vector store in either framework is a one-liner. This is why Chroma appears in the majority of RAG tutorials: the barrier to a working demo is lower than any alternative.

Where friction surfaces is at the transition to real use. Moving from embedded to client-server mode requires running a separate process. Moving to Chroma Cloud requires updating the client initialization and managing API keys. Neither is complicated, but both require work that catches developers who assumed "it would just scale."

The ingestion experience for large datasets received criticism at the Chroma Cloud launch on Hacker News in August 2025. One developer reported that indexing 1.2M documents took days and was fragile. The team acknowledged this and cited Chroma Sync as the structured answer, but users who need to bulk-load tens of millions of documents should test ingestion time before committing to the platform.

"The main reason I chose ChromaDB was that it lets you play with the results. It gives you more room to work on your pipeline and experiments." - Ismail Aslan, Machine Learning Engineer at AltexSoft, 2025

Who Chroma is built for

Chroma is built for developers in the early-to-mid stages of an AI application. Specifically: ML engineers prototyping retrieval pipelines who want to swap embedding models without re-architecting infrastructure. Data scientists building RAG proof-of-concepts for stakeholder review. Application developers integrating semantic search who do not want to provision and manage a separate database service. Teams in the LangChain or LlamaIndex ecosystem who want a zero-config local backend.

Chroma Cloud extends the target to small production deployments with moderate concurrency and collections under a few million vectors. The $250/month Team plan includes SOC 2 compliance and Slack support, which covers the needs of many early-stage SaaS products.

The community describes Chroma as "the SQLite of the vector world," which is accurate in both directions: fast to adopt, widely used in development, but with documented limits that send serious production traffic elsewhere.

What Chroma is not

Chroma is not a distributed database. The open-source version is single-node. There is no built-in replication or high availability. If the machine running Chroma goes down, the service is down. This is fine for development and acceptable for small internal tools. It is a meaningful gap for production systems requiring 99.9%+ uptime.

Chroma does not provide multi-tenancy isolation in the open-source version. Building a SaaS product where different customers' data must be isolated requires either separate collections per tenant (manageable at small scale, painful at hundreds of tenants) or a different database architecture.

Chroma does not support GPU-accelerated vector search. All indexing and retrieval is CPU-based. For workloads at hundreds of millions of vectors or requiring sub-millisecond latency at high concurrency, CPU-only search becomes the bottleneck.

Azure-primary teams face additional friction: Chroma has no native Azure integration. Deployment on Azure requires Docker containers rather than first-party managed service support. Teams deeply invested in the Azure ecosystem may find Azure AI Search or Cosmos DB simpler to operate.

The Chroma Cloud launch timeline is also worth noting. Chroma Cloud was promised for end of 2023 and went generally available in August 2025, roughly two years late. The product arrived with solid features, but the slip was long enough that many developers who needed managed hosting had already moved to Pinecone or Weaviate. Whether the delay affects your decision depends on how central Chroma Cloud is to your architecture versus the self-hosted option.