This episode digs into the history and background behind the birth of ChromaDB, its evolution from version 0.x to 1.x with a Rust server, and the real problems it solves: million-scale embedding storage, semantic search, and fast integration with LLM frameworks.

Episode 0 made sure your environment is ready. Now it is time to understand why ChromaDB exists. Episode 1 answers three big questions: where ChromaDB comes from, what problem it solves, and why you — as an engineer building RAG — need it.
Many people start using ChromaDB because of a tutorial, even though understanding its background is far more valuable. By knowing the problem it solves, you will find it easier to decide when to use ChromaDB, when not to, and how to position it in your application architecture. Let's start from the beginning of the story.
ChromaDB was built by the company Chroma, founded by Jeff Huber around 2022. Its vision from the start was not just to make "a vector database", but to build search infrastructure for AI — search infrastructure designed specifically for the needs of AI applications, where what you search for is not an exact string match, but the closest meaning.
In 2023 ChromaDB began circulating with the 0.x version, and quickly caught the community's attention for three reasons: it was extremely easy to use (only one line to start), it ran locally without a server, and it integrated seamlessly with rising LLM frameworks like LangChain and LlamaIndex.
ChromaDB's journey entered a major chapter in 2025-2026 with the release of version 1.x. The most fundamental change was the introduction of the Rust server for production, replacing the Python FastAPI server used in the previous era. The following table summarizes the journey:
| Period | Version | Key Point |
|---|---|---|
| 2023 | 0.x | Initial release, focused on ease of use |
| 2025 | 1.0.x | Stable API, tenant/database model |
| 2025-2026 | 1.5.x | Rust server, weekly releases, security patches |
| 2026 | 1.5.9 | Latest stable, fixes CVE-2026-45829 |
The decision to use a Rust server was not without reason: more deterministic performance, a smaller memory footprint, and stricter security. We will dissect the differences between the two servers in depth in episode 2.
Thanks to its ease of use and ecosystem, ChromaDB became one of the most widely used open-source vector databases. As of 2026, the chromadb package on PyPI records around 13 million downloads per month. This is not just for show — it means a large community, abundant documentation, and maintained releases. On GitHub, the chroma-core/chroma repository records more than 28,900 stars.
pip show chromadb | grep -i versionThe command pip show chromadb | grep -i version shows the installed version. Regular checks like this matter because ChromaDB releases every Monday — there is always something new to evaluate.
Before vector databases matured, teams building semantic search had to build everything themselves: storing vectors, computing similarity, and performing nearest-neighbor searches. This is hard. ChromaDB abstracts all of it: you only need to add documents and query; indexing and ANN are handled behind the scenes.
Imagine a corpus with a million documents. Linear search — comparing a query to every document — can take a long time. ChromaDB uses HNSW (Hierarchical Navigable Small World) to speed this search down to milliseconds. We will examine HNSW and its trade-offs in episode 9.
The second problem solved is the type of search. AI applications need more than just keyword matching:
ChromaDB combines all of these in one engine. Later, in episode 8, we will see how hybrid search — combining vector and keyword — produces far more accurate retrieval for RAG.
The third problem: as RAG became popular, teams had to connect a vector database to their existing LLM pipelines. ChromaDB answered by providing official adapters for LangChain and LlamaIndex, so you can turn ChromaDB into a retriever in just a few lines of code:
from langchain_chroma import Chroma
retriever = Chroma(
collection_name="dokumen",
persist_directory="./chroma-data",
).as_retriever()
hasil = retriever.invoke("Apa itu RAG?")We will study this code fully in episode 18. For now, just understand that Chroma(...).as_retriever() turns ChromaDB into a retrieval component ready for an LLM pipeline.
Let's summarize in the context of real work. You need ChromaDB if:
Conversely, if you need massive enterprise scale with multi-node, complex tenancy quotas, or strict ACID transactions, consider alternatives like Qdrant, Milvus, or Weaviate — a full comparison will be covered in episode 22.
To understand ChromaDB's role, look at how it sits in the technology stack of an AI application:
aplikasi (RAG, chatbot, agent)
└── framework LLM (LangChain, LlamaIndex)
└── ChromaDB (retrieval & memory)
└── model embedding (MiniLM, OpenAI)ChromaDB's layer sits right below the LLM framework — it provides the retrieval and long-term memory that AI agents need. The embedding model produces vectors, ChromaDB stores and searches them, the framework wires everything into a pipeline, and the application serves users. Understanding this position helps you place ChromaDB correctly when designing your architecture.
Info
Choosing a vector database is not a one-time decision. Many teams start with ChromaDB because it is fast, then move or adopt another as scaling needs change. Understanding this background helps you make the right decision at the right time.
Episode 1 gave you the context: ChromaDB was born around 2022 as search infrastructure for AI, evolved from 0.x to 1.x with a Rust server, and is now one of the most widely used open-source vector databases with around 13 million downloads per month. It solves three major problems: million-scale embedding storage, semantic and full-text search in one engine, and fast integration with LLM frameworks.
Key takeaways:
In the next episode, episode 2, we will discuss core concepts and main architecture — the Collection data model with ids, embeddings, documents, and metadatas, the difference between embedded mode versus client-server, and the HNSW-based index and query flow. This is the architectural foundation that will accompany the entire series.