chroma vs weaviate: an embedded library against a multi-tenant database server

One is a library you import, the other is a server you run

Chroma and Weaviate sit at different layers of the stack, and that difference answers most practical questions before you write any code.

Chroma's README describes a library with a deliberately small surface: the core API is four functions, and the flow is create a client, create a collection, add documents, query. A collection holds documents, metadata and embeddings, and by default the library handles tokenization, embedding and indexing for you, while still accepting embeddings you computed elsewhere. The same client moves from memory to a server process with `chroma run --path /chroma_db_path`, so a prototype does not need rewriting when the data stops being temporary.

Weaviate stores objects and vectors together. A record carries its properties and its vector in the same place, and one query interface combines vector similarity with keyword filtering, retrieval-augmented generation and reranking. That is a different shape rather than a different logo: in Chroma the query path is a thin client call, in Weaviate the query path is a database server that carries multi-tenancy, replication and role-based access. One is a dependency imported into an application, the other is infrastructure you deploy, monitor and patch.

The first hour: pip install chromadb against docker compose up

Both run quickly, but the minutes go to different things.

Chroma's README gives three install paths: `pip install chromadb` for the Python client, `npm install chromadb` for JavaScript, and `chroma run --path /chroma_db_path` for client-server mode. Prototyping starts with `client = chromadb.Client()`, which the README describes as in-memory, and persistence arrives by pointing the client at that server.

Weaviate's README lists Docker, Kubernetes and Weaviate Cloud as installation options, with marketplace guides for AWS and GCP. The local path is a compose file with two services: the database image `cr.weaviate.io/semitechnologies/weaviate:1.36.0` publishing ports 8080 and 50051, with `ENABLE_MODULES: text2vec-model2vec` and `MODEL2VEC_INFERENCE_API` pointing at a second service, `cr.weaviate.io/semitechnologies/model2vec-inference:minishlab-potion-base-32M`, described as a lightweight embedding model that generates vectors from objects during import. `docker compose up -d` starts both, and `pip install -U weaviate-client` brings the Python client.

The structural difference shows up here. Chroma starts inside your own process, so nothing survives the process unless you start the server. Weaviate starts a service you connect to over REST, gRPC or GraphQL, so the data outlives any one process from the start.

Filtering, hybrid retrieval and reranking are where the two diverge

Search behaviour is where the pair stop looking interchangeable.

Weaviate's README describes a single query interface that combines vector similarity search with keyword filtering, retrieval-augmented generation and reranking, and it names the use cases it is built for: RAG systems, semantic and image search, recommendation engines, chatbots and content classification. Objects carry typed properties, so a filter over those properties is part of the same query as the similarity search rather than a separate lookup. Weaviate also takes pre-computed vectors directly when you would rather embed elsewhere.

Chroma takes the opposite route on embedding. The `add` call takes documents and metadata, and the library does the tokenization, embedding and indexing itself, while the same call accepts your own embeddings when you want to skip that step. The wider search modes live in the hosted offering: Chroma Cloud is described as powering serverless vector, hybrid and full-text search, so the hybrid and keyword paths sit in the service rather than in the open-source client, whose surface stays at four functions.

So the practical question is whether filtering, reranking and hybrid retrieval have to live in the system you run yourself. Weaviate answers that inside its own server. Chroma answers it in the cloud.

Multi-tenancy, replication and role-based access decide shared-service questions

These are the features that separate a database other people depend on from a library inside one process.

Weaviate's README lists built-in multi-tenancy, replication and RBAC authorization among the features production deployments benefit from, and the installation guides include Kubernetes, which is the shape a partitioned shared index tends to take. Nothing has to be bolted on afterwards. The client libraries cover Python, JavaScript and TypeScript, Java, Go and C#/.NET, with REST, gRPC and GraphQL interfaces on the server side.

Chroma does not offer that picture, and its own analysis is blunt about it: do not adopt it if you require a mature, feature-complete database with a stable API and extensive operational tooling. Its answer to the same requirement is the hosted service, where the operational layer becomes Chroma Cloud's problem instead of yours.

If several teams need one index with per-tenant isolation, the Weaviate feature list is the deciding evidence. If each service embeds its own small vector store, Chroma's size is an advantage rather than a limitation, because there is no shared state to protect.

Where chroma stops: four functions, Monday releases and a row-based API to come

Chroma's limits follow from how little it tries to be, and its own documentation is honest about them.

The README calls the core API four functions and notes that a row-based API is coming soon, which means the shape of writes will change after you build against it. The same README documents a release cadence of tagged `pypi` and `npm` versions on Mondays, with hotfixes going out at any time during the week, so a pinned dependency in production needs a plan for when it moves. Our analysis of chroma makes the same point from the other side: test against the latest release and check the roadmap for the features you are about to depend on.

Client-server mode is where the persistence question sits. `chroma run --path /chroma_db_path` starts the server and points it at a directory, and the analysis tells you to verify the persistence model there before you commit, because a client that starts empty each time and a service that survives a restart are different products.

None of this makes Chroma a poor choice for a modest amount of data. It makes it a young choice, and the deciding question is whether you can absorb an API move.

Where weaviate stops: a tutorial image three minors behind the release

Weaviate's limits show up in its own getting-started file, which our analysis treats as the document to read most carefully.

That file pins `cr.weaviate.io/semitechnologies/weaviate:1.36.0` while the current release is v1.39.5, published on 2026-09-15, so copying the tutorial gives you a server several minors behind. Our analysis of weaviate says to pin the server image deliberately rather than copying the compose file.

The embedding choice in the same tutorial is the second trap. The companion service is a lightweight static model, `minishlab-potion-base-32M`, rather than a transformer, and the analysis notes that it will not tell you what relevance looks like in your data. Weaviate itself points to integrated models from OpenAI, Cohere and Hugging Face, or to pre-computed vectors, so that choice is yours to make rather than the tutorial's to make for you.

Two smaller items matter for client code. There are three server interfaces, REST, gRPC and GraphQL, and the analysis says to pick one and stay on it instead of mixing clients. And client-visible removals are tracked as files in a deprecations directory rather than in release notes, so read that directory before writing client code.

Licences, maintenance and the choice for concrete situations

Chroma carries the Apache-2.0 licence, and its last push to the repository was on 2026-10-20, with tagged releases 1.5.9 and cli-1.4.4 published on 2026-05-05. Weaviate's last push was also on 2026-10-20, and its release list shows v1.39.5 on 2026-09-15 next to v1.38.15 and v1.37.17 on 2026-09-14, so patch levels run across several minor lines at once. GitHub does not classify Weaviate's licence and points at the LICENSE file instead, and that file is the document to read if you need the terms rather than the label.

Concrete situations follow.

You want semantic search in a Python service this week and would rather not run a server. Chroma, with `pip install chromadb` and an in-memory client.

You are prototyping an agent whose tools will move to production and you want the client code to stay the same. Chroma, because `chroma run --path /chroma_db_path` keeps the same API in server mode.

You need one index for several teams, with tenants and permissions. Weaviate, because multi-tenancy, replication and RBAC are built in.

You need reranking and hybrid retrieval in the system you operate yourself. Weaviate.

You want the shortest path to a hosted setup with hybrid and full-text search and running a database is not your job. Chroma Cloud.

Before committing, read the Weaviate deprecations directory and pin the server image on purpose, and read Chroma's roadmap against the row-based API you may be about to build on.

Bottom line

Chroma is the right pick when you want vectors working inside a Python process in minutes and can follow a fast-moving API, because four functions and one server command cover the prototype path; Weaviate is the right pick when several teams share one index with tenants, permissions and reranking, because those are features of its server rather than projects you assemble yourself. Verify first: for Chroma, the persistence model in client-server mode and the row-based API on the roadmap, for Weaviate, the server image you pin and the deprecations directory. The judgement worth keeping is that Chroma is a dependency you import and Weaviate is a database you operate, so choose by who is allowed to run the thing rather than by which API reads smaller.

Sources

1. chroma-core/chroma repository
2. chroma-core/chroma README
3. weaviate/weaviate repository
4. weaviate/weaviate README