chroma vs qdrant: embedded simplicity versus engineered scale
Chroma optimises for time-to-first-query: an in-process store with a four-function API and automatic embedding, aimed at prototypes that may later move to a server or cloud. Qdrant optimises for production search: a Rust service with payload filtering, multiple vector types and sharding. They overlap on the basics but diverge on what they ask of you, so the real decision is how much operational surface you want to own.
At a glance
| Project | chroma-core/chroma | qdrant/qdrant |
|---|---|---|
| Licence | Apache-2.0Permissive: commercial use allowed | Apache-2.0Permissive: commercial use allowed |
| Maintenance | Commits in the last six monthsLast push September 25, 2026 | Commits in the last six monthsLast push September 29, 2026 |
| Language | Rust | Rust |
| GitHub stars | 29,377 | 34,881 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose chroma if you want a vector store running inside your Python or JavaScript process in minutes, with tokenisation, embedding and indexing handled for you, and you accept that the API is still moving (the README notes a row-based API is coming) and that client-server persistence and operational tooling are less mature than the alternative.
Choose qdrant if you need a standalone service with a stable REST and gRPC API, rich filtering on payloads, dense, sparse and multi-vector search, and sharding for scale, and you are willing to run and secure a server process (the container command the README gives starts without authentication).
Two different answers to where the database should live
Chroma's README leads with a library call, not a server. The setup snippet is `pip install chromadb`, and the first example constructs an in-memory client with `chromadb.Client()`. The README says persistence can be added easily, and client-server mode is a separate command: `chroma run --path /chroma_db_path`. The core API is described as four functions, and the README states that Chroma handles tokenisation, embedding and indexing automatically, while allowing you to supply your own embeddings. That is the design centre: the database is a Python or JavaScript object you create, and the server is an option you graduate to.
Qdrant inverts this. Its README describes a production-ready service with an API to store, search and manage points, where a point is a vector plus a payload. The local experience is a container: `docker run -p 6333:6333 qdrant/qdrant`. A client then connects over HTTP, for example `QdrantClient(url="http://localhost:6333")`. The README frames Qdrant around extended filtering support for semantic matching and faceted search, and says it is written in Rust so it holds up under high load. There is an embedded variant, Qdrant Edge, which runs inside the application process with a smaller footprint and can synchronise with a Qdrant server, but the README presents it as a companion for edge devices and offline use, not as the default way to run Qdrant.
The practical consequence is where your data lives. With Chroma, a prototype's vectors live in the same process as your script, and moving to `chroma run` changes the deployment shape. With Qdrant, the server is the unit from the first command, and the embedded path is the special case.
Getting a first query out of each
Chroma's path is short by construction. Install the package, create a client, create a collection, add documents. The README example adds two documents with metadata and notes that you can skip the built-in embedding and pass your own. The README also advertises a Google Colab notebook for the four-function API, and Chroma Cloud is described as letting you create a database and try it in under 30 seconds with $5 of free credits. For a Python or JavaScript developer, the first working query is a single file.
Qdrant's path is a server plus a client library. The README's quick start is the Docker command above, followed by connecting a client. It then points at installation and security guides before production, and the container command carries an explicit warning: it starts an insecure deployment without authentication, open to all network interfaces. That warning is the honest cost of the client-server model. You also choose a client from a longer list: Go, Rust, JavaScript/TypeScript, Python, .NET/C#, Java officially, with Kotlin and PHP community clients. If you want the embedded route, the README shows Qdrant Edge in Python or Rust by initialising an `EdgeShard`, with an example that creates a shard on disk, defines a vector named `my-vector` with size 4 and cosine distance, and upserts a point with a payload.
Neither setup is hard. They differ in what you must decide before the first query. Chroma hides the embedding and indexing decision; Qdrant asks you to name the vector, its size and its distance function, which is the same information you will need later when you tune recall.
Filtering, vector types and the shape of a query
The clearest functional gap is in what a query can constrain. Qdrant's README states it is tailored for extended filtering support, and the earlier analysis notes it pairs dense, sparse and multi-vector search with rich payload filtering, aimed at production workloads that need similarity matching and precise metadata constraints. That combination is the reason faceted search is named in the README. If your retrieval needs to say "similar to this, but only where tenant equals X and status is active", Qdrant treats the filter as a first-class part of the search rather than a post-processing step.
Chroma's README shows metadata attached to documents at add time, and the core API is four functions. The README does not describe sparse vectors, multi-vector search or a filtering language, and the earlier analysis does not claim them. It does flag that a row-based API is coming, which tells you the data model is still being filled in. For a prototype over a single collection with light metadata, this is not a limitation you will feel. For retrieval that mixes semantic similarity with structured constraints across many fields, it is the deciding difference, and the answer favours Qdrant.
A second difference sits in the API contract itself. Qdrant's README points to a hosted API reference (api.qdrant.tech) and offers REST plus client libraries across seven official languages. Chroma's README points to its docs and a Colab, and the earlier analysis warns that the API surface is still moving and should be verified against the latest release. A stable, documented API matters more as the number of services calling the database grows, and that is a point in Qdrant's favour for platform teams.
Running it on a bad day: persistence, scaling and upgrades
Chroma's operational story has two modes that behave differently. In-process, the README's first example is explicitly in-memory, and the README says persistence can be added easily, which is not the same as describing how durability, backups or recovery work. In client-server mode you pass `chroma run` a path, and the earlier analysis says the persistence model in client-server mode is one of the things to verify before committing. The README does not document rollback, and it does not describe sharding, replication or a migration path between the in-process and server modes. The release cadence is stated: tagged pypi and npm packages go out on Mondays, with hotfixes during the week. Frequent releases plus a moving API means upgrades deserve a test pass, not a blind bump.
Qdrant's operational surface is larger and more explicit. It is a service with a REST and gRPC API, which is the shape you want when several applications or languages share one index. The earlier analysis flags sharding and quantisation as tuning knobs to verify against release notes, and warns that the project ships frequently and you should check the changelog for breaking changes before upgrading. That is a real cost, but it is a cost paid by an operator who already has a service to upgrade. The README's own security warning is the first operational task: the default container is open, and the security guide is where you close it.
Neither project is a set-and-forget appliance. Chroma asks less of you until you leave the in-process mode, at which point its operational documentation is thinner. Qdrant asks more from the first command, and in return gives you the pieces (API, filtering, sharding, quantisation) that production work eventually needs.
Where each one is the weaker choice
Chroma is the weaker choice when the database must be a shared, long-lived service. Its README does not document sharding, replication or rollback, and the earlier analysis warns against adopting it if you require a mature, feature-complete database with a stable API and extensive operational tooling. The API is still growing: the README says a row-based API is coming, and the earlier analysis says to verify the current API surface and the client-server persistence model before committing. It is also the weaker choice when retrieval needs structured filtering at depth, because the README does not describe a filtering language or sparse and multi-vector search. None of this is a flaw in a prototyping tool; it is a mismatch when the tool is asked to be a platform.
Qdrant is the weaker choice when the requirement is a fully embedded database with no server process. The README's own framing puts the client-server architecture first and presents Qdrant Edge as the in-process alternative, with a smaller footprint and a different API surface (EdgeShard rather than a client URL). The earlier analysis says to avoid Qdrant if you need a fully embedded database with no server process, unless Qdrant Edge fits, and notes Edge still runs in-process but with a smaller footprint. Qdrant is also the weaker choice when you want the database to disappear into a script: it asks you to run, secure and upgrade a service, and it asks you to choose vector size and distance up front. For a notebook, that is ceremony you may not want.
Licence and maintenance: same licence, different release discipline
Both projects ship under Apache-2.0, and both repositories show a last push of 2026-09-14, so neither is archived and neither is stale by the measure of recent activity. The licence is permissive in both cases, which removes the source-available question from the decision. The earlier analyses both say to verify the licensing terms before committing, which is standard caution rather than a known problem in either repository.
The maintenance difference is in cadence and in what the cadence implies. Chroma's README states tagged pypi and npm releases go out on Mondays with hotfixes during the week, and the earlier analysis calls it a young project with weekly releases that is evolving quickly. Qdrant's earlier analysis describes frequent releases and tells you to check the changelog for breaking changes before upgrading. Both are moving, so the question is not which one is maintained but which one's change rate matches your tolerance. A weekly package release against a four-function API is easy to absorb in a prototype. A frequently released server with a gRPC surface and sharding configuration is a different kind of upgrade risk, and it lands on whoever operates the cluster.
The earlier analysis of Chroma also points at the roadmap, including the row-based API, as something to check. That is a signal about the data model rather than the release schedule, and it is the kind of change that can ripple through application code. Qdrant's README, by contrast, points at a versioned API reference, which is the artefact you want when multiple teams pin a client version.
Choosing for a notebook, a service and a mixed stack
For a notebook, a demo, or a retrieval feature inside one Python or JavaScript application, Chroma is the shorter path. The README's install line, in-memory client and automatic embedding are exactly the decisions you do not want to make on day one, and client-server mode with `chroma run --path` is available when the prototype outgrows the process. Accept the trade: verify the API surface and the client-server persistence model against the release you are actually installing, and do not assume the README documents rollback, because it does not.
For a search service behind an API, shared by several applications or languages, with filters that must be applied precisely, Qdrant is the better fit. The README's client-server architecture, REST and gRPC APIs, extended filtering and official clients in seven languages are the pieces a platform team needs, and the earlier analysis names dense, sparse and multi-vector search plus payload filtering as the reason to adopt it. Budget for the operational work the README itself flags: the default container is unauthenticated and open, so read the security guide before it faces a network, and read the changelog before each upgrade.
A mixed stack is reasonable and the two are not mutually exclusive. Chroma can hold the working set for a single service or a notebook, while Qdrant serves the shared index that needs filtering and scale. If you want one engine everywhere, Qdrant Edge is the README's answer for in-process use, but it is a distinct API from Qdrant Server, so treat it as a second integration to test rather than a drop-in.
Bottom line
Pick Chroma when the goal is a working retrieval loop today inside one Python or JavaScript process, and when you can absorb a moving API and a persistence model the README does not fully document. Pick Qdrant when retrieval is a shared service that needs precise payload filtering, several vector types and a documented REST or gRPC contract, and when you are prepared to run, secure and upgrade a server. Before committing, verify two things in the release you will actually install: for Chroma, the current API surface and how client-server mode persists data; for Qdrant, the changelog for breaking changes and the security steps that close the unauthenticated default container. The licence is identical, so the decision rests on deployment shape, filtering depth and who owns the upgrade.