Open-source AI-native vector database for building LLM-powered applications with embeddings
An open-source, AI-native vector database that stores embeddings and runs similarity search for LLM apps.
It is the fastest way to add retrieval to an AI app: a few lines of Python and you have a working vector store.
| Category | Vector |
| First released | 2022 |
| Latest release | 1.5.9 (May 2026) |
| License | Apache-2.0 |
| Written in | Python, Rust |
| Runs on | Linux, Macos, Windows |
| Deployment | Self-hosted, Managed, Embedded |
| Wire protocol | http |
| Query dialect | |
| Consistency | strong |
| ACID support | no |
| JSON support | native |
| Full-text search | native |
| Vector support | native |
| HA model | none |
| Managed by | chroma-cloud |
Chroma, often called ChromaDB, is an open-source vector database built for AI applications. Instead of rows and columns, it stores embeddings, the numeric vectors that models produce from text, images, or audio, and finds the ones closest in meaning to a query. That makes it the retrieval layer behind retrieval-augmented generation, semantic search, and agent memory, where the job is to fetch the most relevant context and hand it to a language model.
The project was created by Chroma Inc., a San Francisco company founded in 2022 by Anton Troynikov and Jeff Huber, and the first open-source release landed in October 2022. It is written in Python and Rust and licensed under Apache-2.0. The design goal from day one was developer experience: make the path from a laptop prototype to a running vector store as short as possible, which is why so many first RAG tutorials reach for Chroma.
Chroma spread quickly through the LangChain and LlamaIndex communities, where it became a common default vector store, and it now sees millions of monthly downloads. In 2026 the company shipped Chroma Cloud, a managed service that runs the same open-source core. Named production users include Mintlify, which powers per-customer documentation search on it, code-review company Propel, Weights & Biases, Capital One, and UnitedHealthcare.
Chroma runs in a few modes from the same API. In embedded mode it lives inside your Python or JavaScript process, either fully in memory or with a persistent client that writes to a local directory. For shared access it runs as a server you talk to over HTTP, and Chroma Cloud is that server hosted for you. The same client code works across all of them, so a prototype can graduate to a server without a rewrite.
Data lands in collections. When you add documents, Chroma runs them through an embedding function to produce vectors, or you pass vectors you already have. It stores each vector alongside the original document and a metadata dictionary. Metadata and document text sit in SQLite in the local build, while the vectors go into a separate index tuned for nearest-neighbor math rather than row lookups.
A query gets embedded the same way, then Chroma searches an HNSW index, a graph structure that walks toward the nearest vectors without scanning every one, and returns the closest matches by cosine, L2, or inner-product distance. You can attach a where filter on metadata so the search only considers documents that match, and combine vector similarity with keyword matching for hybrid retrieval. The newer Rust core rewrote these hot paths for throughput.
A collection is Chroma's core container, the rough equivalent of a table. Each holds documents, their embeddings, and metadata under one name, and you create, query, and delete at the collection level. A collection has one distance function and one embedding function, so every vector inside it stays directly comparable.
Embeddings are the numeric vectors that represent meaning, and they are what Chroma indexes and searches. You can hand Chroma raw text and let its embedding function call a model to produce the vectors, or compute them yourself with OpenAI, Cohere, or a local model and pass them in. Similar content lands in nearby vectors.
Each record pairs a vector with the original document text and a metadata dictionary of key-value fields. Metadata is where you keep source, author, timestamp, or tags, and it drives filtering at query time. Chroma keeps the text and metadata in SQLite in the local build, so you can retrieve source content alongside the vector search.
A query is embedded into the same vector space, then Chroma returns the nearest documents by distance rather than exact matching. You pick the metric per collection: cosine, squared L2, or inner product. Results come back ranked with documents and metadata attached, exactly the context shape a RAG prompt needs to ground an answer.
Vector search rarely runs alone. A where clause filters on metadata fields with operators like equals, greater-than, in, and boolean and/or, and a where_document clause matches text inside documents. Chroma applies these so a query only considers passing records, narrowing to one tenant, source, or date range before ranking.
Under the hood Chroma indexes vectors with HNSW, Hierarchical Navigable Small World graphs, the standard structure for fast approximate nearest-neighbor search. Rather than compare a query against every stored vector, HNSW walks a layered graph toward the closest ones, trading a little recall for a large speedup you can tune.
Live GitHub adoption, updated daily
A handful of the companies running it in production
The core use case. Store your document embeddings, retrieve the closest chunks to a question, and feed them to a language model as grounding context. Chroma's API is built around exactly this loop.
Embedded mode needs no server, so you go from pip install to a working vector store in minutes. It is the shortest path to test whether semantic search or retrieval helps your product at all.
Search by meaning rather than keywords, so a query finds related passages even with no shared words. Metadata filtering narrows results to a tenant, source, or date range before ranking by similarity.
Give an agent recall by embedding past turns, notes, or documents and fetching the relevant ones on demand. LangChain and LlamaIndex integrate Chroma directly, so it slots into existing agent stacks.
Chroma has no ACID transactions, joins, or SQL. Orders, accounts, and anything that must stay consistent under concurrent writes belong in Postgres or another relational database, not a vector store.
It answers nearest-neighbor queries, not group-bys, rollups, or column scans over billions of rows. For reporting and analytical workloads an engine like ClickHouse or DuckDB is a far better fit.
Self-hosted Chroma runs as a single node with no built-in replication or failover. For large, always-on workloads you either lean on Chroma Cloud or reach for a more battle-tested distributed engine.
Chroma shines for small to mid-size corpora and quick iteration. At very large vector counts with strict latency targets, Qdrant, Milvus, or Weaviate offer more tuning knobs and horizontal scaling.
Head-to-head specs against the top 4 alternatives
| Spec | |||||
|---|---|---|---|---|---|
| Identity | |||||
| License | Apache-2.0 | Proprietary | Apache-2.0 | BSD-3-Clause | Apache-2.0 |
| First released | 2022 | 2021 | 2021 | 2019 | 2019 |
| Capabilities | |||||
| ANN algo | hnsw | proprietary | hnsw | HNSW | hnsw, ivf, diskann, scann |
| Hybrid search | Native | Native | Native | Native | Native |
| Vector | Native | Native | Native | Native | Native |
| Ecosystem | |||||
| Managed providers | 1 | 1 | 1 | 1 | 1 |
| Integrations | 4 | 4 | 11 | 4 | 7 |
| Use cases | |||||
| Best for | AI/LLM applications, RAG pipelines, semantic search, and rapid prototyping of embedding-based apps | Production-scale vector search with zero infrastructure management and enterprise security requirements | Semantic search, RAG pipelines, recommendation engines, image similarity, and AI agent memory with advanced filtering | Semantic search, RAG pipelines, and AI-native applications requiring hybrid vector and keyword search | Large-scale vector similarity search, RAG applications, and AI-powered recommendations |
| Not ideal for | General-purpose data storage, OLTP, analytics, or production workloads requiring high availability | Self-hosted deployments, on-premise requirements, cost-sensitive prototyping, or workloads needing open-source flexibility | Traditional relational queries, OLTP workloads, time-series data, or use cases not involving vector embeddings | Traditional relational workloads, complex transactions, or use cases requiring strong ACID guarantees | Traditional relational data, OLTP workloads, or applications not using embeddings |
Install Chroma, create a collection, add a few documents, and run a similarity query. Under a minute in pure Python, no server needed.
pip install chromadbimport chromadb
# In-memory for a quick test; use PersistentClient to save to disk
client = chromadb.Client()
collection = client.create_collection(name="docs")collection.add(
documents=[
"Chroma is an open-source vector database.",
"Postgres is a relational database.",
],
ids=["doc1", "doc2"],
)results = collection.query(
query_texts=["What should I use for embeddings?"],
n_results=1,
)
print(results["documents"])The query returns the Chroma document, not the Postgres one, matched by meaning rather than keywords. From here, swap in your own embedding model or point a client at a Chroma server.
High-performance open-source vector database for next-generation AI applications
High-performance cloud-native vector database built for scalable similarity search and AI applications
AI-native vector database with hybrid search and built-in model integration
The world's most advanced open-source relational database
The most popular document database for modern applications
Fast in-process analytical database with rich SQL support and zero dependencies
Connect to Chroma in 30 seconds. Browse tables, run queries, and edit rows visually, on localhost, self-hosted, or cloud.
Open Chroma in 1bench