Most write-ups of Chroma in 2026 open with the Rust rewrite and the word fast. That is true and it is the least useful thing to know. The 1.0 release in April 2025 rebuilt the core in Rust — WAL3, garbage collection, real multithreading without the Python GIL in the way — and the current 1.5.9 line is genuinely quick. But speed is not the decision. The decision is one architectural choice Chroma made that quietly determines whether it fits your product at all: Chroma serves your index from object storage, not from SSD.

Get that one fact straight and every other question about Chroma answers itself.

The 4x number is not the number you think#

First, defuse the headline. Chroma's launch page for 1.0 says "4x faster." That figure is measured against Chroma's own pre-1.0 Python engine — not against Pinecone, Weaviate, or Milvus. There is no first-party Chroma benchmark I can find that puts a competitor's numbers next to its own. So read "4x" as "much faster than old Chroma," which it is, and nothing more. If you are choosing between vector databases on performance, the honest move is still to run your own eval on your own corpus. Anyone who quotes Chroma's 4x as a competitive win is quoting it wrong.

"4x faster" means four times faster than last year's Chroma. It says nothing about the database you're actually comparing it against.

Where the index lives is the whole story#

Single-node Chroma — the thing you get from pip install chromadb — keeps an HNSW index in memory and on local disk. That is the right tool for a prototype, an embedded app, or a small hot corpus, and it is where most people meet Chroma.

Distributed Chroma, which is what Chroma Cloud runs, is a different machine. It splits the database into two roles: compactor nodes build indices and write them to object storage (S3-class), and query nodes read those indices back through a local cache, with a distributed write-ahead log providing durability ahead of compaction. The index it uses at scale is SPANN — a partition-tree-plus-posting-lists design built for datasets too large to fit one machine's RAM — rather than the single-node HNSW.

The API is identical across both, which is the genuinely nice part: moving from a local PersistentClient to a hosted CloudClient is a client swap, not a rewrite. But do not let the shared API fool you into thinking it is the same system underneath. It is not.

What object storage buys and what it costs#

Serving search from object storage instead of a replicated SSD fleet is a deliberate bet, and it has two edges.

The upside is economics. Object storage is roughly an order of magnitude cheaper per gigabyte than SSDs, and — more importantly — it decouples how much data you store from how much hardware you provision. You do not size a cluster to your corpus; you write to a bucket and the query nodes cache what they need. For a retrieval corpus that grows unpredictably, that is a real operational relief.

The cost is latency. Reading an index out of S3-class storage lands you in the tens-of-milliseconds range — think roughly 35–100ms at the tail — not the sub-10ms you can hit with an in-memory or SSD-resident index. For a RAG pipeline where a retrieval is one step in a multi-second LLM call, nobody will ever notice those milliseconds. For a low-latency, high-QPS serving path where vector search is the product, they matter, and this is the wrong architecture for that job. That is when you reach instead for an embedded engine like LanceDB or sqlite-vec, or a pgvector / Pinecone / Qdrant hot store.

The lever nobody talks about: forking#

Here is the feature that actually follows from the object-storage design and that competitors can't cheaply copy. Because indices live as immutable objects in storage, Chroma Cloud can fork a collection instantly — a copy-on-write branch that shares the parent's data and charges you only for what diverges. No re-indexing, no full copy.

If you have ever cloned a whole vector index just to test a re-embedding or an eval variant, you know that operation is slow and expensive on an SSD-bound store. On Chroma it is close to free. That makes forking a quiet superpower for three jobs founders actually have: running evals against a frozen snapshot, A/B testing a retrieval change without touching production, and provisioning per-tenant copies in a multi-tenant app. It is the clearest case of the architecture paying a dividend beyond cost.

So: is Chroma right for you?#

Skip the benchmark theater and answer one question — what shape is your retrieval load?

The Rust rewrite is why Chroma is fast enough to take seriously. The object-storage bet is why it is cheap and hands-off at scale — and why, for the wrong workload, it is the wrong answer no matter how fast the core got. If you want the wider field, we put it next to its peers in Chroma vs Weaviate vs Milvus. But the fork in the road is right here, and it runs through where your index lives.