Leaving Chroma Cloud
Disclaimer. These guides and the scripts they link are provided as is, without warranty of any kind, as stated in the Apache License 2.0. They describe what we measured on 25 October 2026: your data, versions and setup may behave differently. Back up your data and test the migration on a copy first. You are responsible for your data and for every migration you run.
Not sure about your case? Open an issue in the VecturaDB repository, describe your data and your setup, and we will take a look on a best-effort basis.
Chroma Cloud stops accepting writes on 22 November 2026. It stops serving reads on 22 December 2026.
In our tests no data was lost. On each of the three destinations every record arrived with its document, metadata, embedding and URI, and verify.py found every record the same as on Chroma Cloud. What depends on the destination:
- the settings of the dense index arrive only on Chroma distributed: Chroma 1.5.9 and VecturaDB use HNSW with its default settings, where Chroma Cloud uses SPANN;
- Chroma 1.5.9 cannot hold sparse vectors: our script copies everything else and keeps the sparse vectors in a file, one line per record;
- collections created with the old
hnsw:*settings in their metadata stop the CLI on every destination, and need our script; if their metadata hold sparse vectors, our script keeps those in a file, one line per record.
These guides take you from Chroma Cloud to the place you choose, with tools we build and test for that move:
- the
chromaCLI of VecturaDB, which copies your collections out of Chroma Cloud; verify.py, which compares every copied collection with Chroma Cloud;- for .NET, the ChromaDotNet libraries: client, Local, Aspire and Testcontainers;
- for Docker, Python and JavaScript, VecturaDB itself, when you need what only Chroma Cloud had.
VecturaDB and ChromaDotNet are our projects. They are not affiliated with Chroma. Chroma itself is a first-class destination here, and for many users it is the right one.
We ran every command and every line of code in these guides against Chroma Cloud and against the destination before writing it. The numbers come from those runs.
Where you go
If you use only dense search, with metadata filters and document filters, Chroma 1.5.9 is enough. It is one container or one Python package, and it holds every record that Chroma Cloud gives back.
If you use sparse vectors, BM25, the Search API or hybrid search, the single-node Chroma 1.5.9 cannot hold those collections: you need Chroma distributed or VecturaDB.
| Chroma 1.5.9, single node | Chroma distributed | VecturaDB 1.0.0-preview.3 | |
|---|---|---|---|
| Dense search | Yes | Yes | Yes |
| Metadata filters | Yes | Yes | Yes |
Document filters: $contains, $regex |
Yes | Yes | Yes |
| Sparse vectors | No: "Sparse vector indexing is not enabled in local" | Yes | Yes |
| BM25 | No, same error | Yes | Yes |
| Search API | No: "Search operation is not implemented for local executor" | Yes | Yes |
| Hybrid search (RRF) | No | Yes | Yes |
| Collection fork | No: "Collection forking is unsupported for local chroma" | Yes | Yes |
| Copy from Chroma Cloud | Dense collections, with the CLI of VecturaDB; the others with our script | Every collection, SPANN settings included | Every collection, with the CLI of VecturaDB; dense index settings become HNSW defaults |
| Embedding models hosted by Chroma Cloud | Stop with Chroma Cloud. The same open models run locally give the same search results in our tests | Same | Same |
| API keys | None: the open-source server accepts every request | None: the same server code | Yes: keys per tenant and database, in the x-chroma-token header, as on Chroma Cloud |
| What you run | One container, or pip install chromadb; in .NET, also ChromaDotNet.Local |
Kubernetes, several services, object storage and a SQL database | One container, the chroma CLI, or pip install VecturaDB |
On distributed Chroma, Chroma's documentation says:
"Distributed Chroma is designed for large-scale production workloads."
"In distributed mode, Chroma's components are deployed independently."
"The log and built indexes are stored in cloud object storage."
"The system catalog is backed by a SQL database."
Source: Distributed Chroma, Chroma documentation.
Where you start from
| You use | To Chroma 1.5.9 | To Chroma distributed | To VecturaDB |
|---|---|---|---|
| .NET | ChromaDotNet.Client; ChromaDotNet.Local, without Docker; Aspire; Testcontainers | ChromaDotNet.Client | ChromaDotNet.Client; Aspire; Testcontainers |
| Python | chromadb |
chromadb |
pip install VecturaDB, also without a server |
| JavaScript and TypeScript | chromadb on npm |
chromadb on npm |
chromadb on npm, with VecturaDB as the server |
| Another language | your Chroma client, unchanged | your Chroma client, unchanged | the clients we tested |
| Docker | chromadb/chroma:1.5.9 |
ghcr.io/vecturadb/vecturadb |
On every path you copy with the CLI of VecturaDB and check with verify.py. The guide to Chroma distributed still copies with the CLI of Chroma: we have not yet run the CLI of VecturaDB against a distributed cluster.
The guides
Each guide has the same five steps: start the destination (or, for Chroma distributed, reach it), copy the data, switch the client, replace the hosted embedding models, check the result.
- To Chroma 1.5.9, single node
- To Chroma distributed
- To VecturaDB
- Hosted embedding models, shared by the three guides