Pinecone vs Chroma After Chroma Cloud's Shutdown
November 3, 2026

Pinecone vs Chroma is a different comparison since October 23, 2026. That day Chroma announced it signed a definitive agreement to join Replit and that it is winding down its hosted service. Per Chroma's wind-down timeline, Chroma Cloud turns read-only on November 22, 2026 and stops serving reads on December 22, 2026. Pinecone is the managed service here. Chroma is the Apache-2.0 open-source database you run yourself.
The short version:
- Pick Chroma if you want to prototype offline or keep data on your own machines. You run it, so you own backups, upgrades and scaling.
- Pick Pinecone if you want a managed service with zero database operations and built-in features like server-side embedding, full-text fields and dedicated read capacity.
- If you are on Chroma Cloud, you have to migrate before the dates above. Your options are self-hosted Chroma or a different database such as Pinecone.
Pinecone vs Chroma: quick comparison
| Pinecone | Chroma | |
|---|---|---|
| What it is | Managed serverless vector and search database | Open-source vector, full-text and metadata search database |
| Licence | Commercial service | Apache-2.0 |
| Run it on your laptop | No. The local emulator reached end of life on October 7, 2026 | Yes, in-memory or persistent, no account needed |
| Self-host | No. BYOC (Pinecone runs it in your cloud account) | Yes, chroma run client-server mode |
| Managed cloud | Pinecone (AWS, GCP, Azure) | Chroma Cloud is closing: read-only from November 22, 2026, no reads from December 22, 2026 |
| Metadata filtering | Yes, with $eq, $ne, $in, $exists, $and, $or, $not and more | Yes, with $eq, $in, $nin, $and, $or, array $contains and more |
| Keyword search | Full-text search fields in the same index | $contains and $regex filters over documents |
| Hybrid search | Yes: a text-match filter plus dense search, client-side RRF fusion, or dense plus sparse vectors on the Vectors API | Not documented for self-hosted Chroma (see below) |
| Embeddings | Optional server-side embedding | Default local model, or plug in your own |
| Cost model | Plan minimum plus read units, write units and storage | Free software; you pay for your own servers |
What changed for Chroma
Two pages from Chroma set out the news. The announcement says Chroma signed a definitive agreement to join Replit, and that over the next 60 days it is responsibly winding down its existing cloud service. The wind-down timeline gives two milestones:
- November 22, 2026: Chroma Cloud becomes read-only. Applications can no longer create, update or delete data there.
- December 22, 2026: Chroma Cloud stops serving read requests.
The same timeline page says the change applies only to the existing Chroma Cloud service: "Open-source ChromaDB remains available under the Apache 2.0 license." The announcement adds that Chroma has committed additional code from its private repos to the Apache 2.0 repo, and that Replit will keep contributing to the project.
We are not guessing beyond that. What matters for a build decision today: Chroma is a database you run yourself, and its hosted service is closing.
Local development: where Chroma pulls ahead
This is the biggest practical difference, and it got bigger this autumn.
With Chroma, you start in two lines of Python. The Chroma repo shows chromadb.Client() running an in-memory database "for easy prototyping." Swap to a persistent client and your data is saved to disk and reloaded on start. Chroma's client docs cover an in-memory client and a persistent client, and its client-server mode adds an HttpClient for a server you run. Your code barely changes between them.
Chroma also embeds text for you by default. Its default embedding function uses the Sentence Transformers all-MiniLM-L6-v2 model and "runs locally on your machine." So a first prototype needs no API key at all.
Pinecone has no local database to run. Its local development guide states that Pinecone Local, the in-memory emulator, "reached end of life on October 7, 2026." Pinecone's guide points to two things instead:
- A Prism mock server built from Pinecone's OpenAPI specs, for request-shape and error-handling tests in CI. It stores nothing and returns canned responses.
- A separate Pinecone project for any test that writes data and reads it back, or checks search relevance.
That works, but it means real integration tests need a network connection and a Pinecone account. If you build on a plane, or in a locked-down environment, that's a real cost.
| Dev task | Pinecone | Chroma |
|---|---|---|
| First query with no account | Not possible | pip install chromadb and go |
| Offline work | Mock only, no real search | Full database runs offline |
| CI tests of search quality | Separate Pinecone project | Persistent or in-memory Chroma in the job |
| Same code in prod | Yes, same API | Yes, switch client type (you host the server) |
Hosting: managed only vs run it yourself
Pinecone describes itself as a serverless managed service on AWS, GCP and Azure. Vector data lives in distributed object storage, and reads and writes run on separate paths that "scale independently based on demand." You never size a cluster. If your compliance team needs data inside your own cloud account, Pinecone offers BYOC, which its pricing page lists as an Enterprise feature priced on request.
Pinecone's architecture page describes it as a managed service, so there is no self-hosted edition to run. BYOC is the closest option.
Chroma now has two hosting choices, both run by you:
- Embedded in your Python process, for notebooks, desktop apps and scripts.
- Self-hosted server via
chroma run --path /db_path, then connect over HTTP. You handle backups, upgrades and scaling.
Chroma Cloud was a third choice, and it is closing on the dates above. So the old chroma cloud vs pinecone question is settled by the calendar: for managed hosting, Pinecone is the option left standing in this comparison.
Filtering and hybrid search
Both databases filter on metadata before ranking, which matters for RAG apps that scope answers to one customer, one folder or one date range.
Metadata filtering. Pinecone's filter docs list $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $exists, $and, $or and $not, with $in arrays capped at 10,000 values. Chroma's metadata filtering uses a where argument with equality, comparison, $in/$nin, $and/$or, and array $contains/$not_contains. For most RAG scoping, either is enough.
Pinecone also has namespaces, which keep each tenant's data separate inside one index. That's handy for multi-tenant SaaS.
Keyword search. Chroma supports full-text search through where_document with $contains, $not_contains, $regex and $not_regex. That's a filter, not a ranked keyword score. Pinecone lets you declare full-text-search fields in the same index as your dense and sparse vectors, with text-match operators like $match_phrase and $match_any.
Hybrid search (mixing keyword and semantic results) is where the two differ most.
- Pinecone's hybrid search guide offers three patterns. "Filter, then rank" applies a text-match filter on a full-text field, then ranks with a dense search. "Client-side fusion" runs a keyword search and a dense search separately and merges them with reciprocal rank fusion (RRF). The third stores a dense and a sparse vector on each record in one index on the Vectors API. For a new document or text workload, the guide points to the Documents API with one field that has both full-text search and embedding turned on.
- Chroma's Search API was announced for hybrid search with RRF and custom ranking expressions, but its docs say it is available in Chroma Cloud only. Chroma Cloud is closing, so we don't count it as an advantage. We make no claim about whether it will reach self-hosted Chroma.
So if hybrid ranking is a hard requirement, Pinecone documents it today and self-hosted Chroma doesn't. With Chroma you'd run a vector query and a $contains or $regex filter, or two queries, and merge the results in your own code.
Cost model: is Chroma free?
Chroma the software is free. Apache-2.0 means you can run it on your own hardware, commercially, with no licence fee. You pay for the machine and the time to run it. Chroma's hosted plans are closing, so we don't price them.
Pinecone is usage-based, with plan minimums. Pinecone's pricing page lists a free Starter plan with storage and read/write unit caps, limited to AWS us-east-1. Above that, the Builder plan is a flat monthly fee, and the Standard and Enterprise plans carry a monthly minimum, then pay-as-you-go on read units, write units and storage. Read and write prices vary by cloud and region.
| Cost driver | Pinecone | Self-hosted Chroma |
|---|---|---|
| Base fee | Plan minimum (free Starter has caps) | None |
| Reads | Read units | Your servers |
| Writes | Write units | Your servers |
| Storage | Per GB per month | Your disks |
| People cost | Close to zero ops | You run it |
Two rules of thumb. A read-heavy app (lots of queries over a stable corpus) should model read units carefully on Pinecone. An app with a big corpus but low traffic often looks cheapest on self-hosted Chroma, as long as someone owns the server. Check Pinecone's pricing page with your own numbers; it changes.
Pinecone vs Chroma performance
You'll find plenty of third-party benchmarks. We're not quoting any, because results depend on your corpus, your embedding size, your filters and how warm the cache is, and each vendor tunes for its own tests.
What the architecture tells you:
- Pinecone separates read and write paths and caches data on SSD and in memory. Its Standard and Enterprise plans add Dedicated Read Nodes, provisioned capacity reserved for one index, for predictable high-throughput reads.
- Chroma embedded mode skips the network hop entirely, which makes small local workloads very fast. A self-hosted server's speed depends on the machine you give it.
The honest test: load a sample of your real data into both, run your real queries with your real filters, and measure. Pinecone's free Starter plan and a local Chroma install are enough for a fair first look.
Migrating: off Chroma Cloud, and between Chroma and Pinecone
If you use Chroma Cloud today, the deadlines come first. Chroma's timeline tells customers to move active workloads to another Chroma deployment or database before November 22, 2026, and to finish exports before December 22, 2026. The destination can be self-hosted Chroma or Pinecone.
Chroma Cloud to self-hosted Chroma is the shortest move. The chroma copy command copies collections between a local Chroma server and Chroma Cloud in either direction, one collection or all of them. Use it with Cloud as the source and a local server as the target.
Chroma to Pinecone takes more work:
- Export from Chroma. Page through each collection with
get, pulling IDs, embeddings, documents and metadata. - Check your embeddings. If you used Chroma's default local model, your vectors are that model's size. Either keep them and create a Pinecone index with the same dimension, or re-embed everything with the model you'll use in production.
- Map metadata and filters. Chroma filters go in
whereandwhere_document; Pinecone's operators are similar but not identical. Rewrite and test each filter your app uses. - Load into Pinecone. Upsert in batches, or, on Standard and Enterprise plans, use bulk import from Parquet files in Amazon S3, Google Cloud Storage or Azure Blob Storage. After the data loads, indexing usually takes at least 10 minutes.
- Replace keyword logic. Chroma's
$containsfilters map to Pinecone's full-text fields or text-match operators, not to vector search.
Pinecone to Chroma is the reverse: list and fetch the records in each namespace, write them into Chroma collections, and map namespaces to separate collections. Keeping a thin storage layer in your app (one module that talks to the database) makes any of these moves much less painful.
Which should you pick for RAG?
Chroma db vs pinecone for rag comes down to your stage and your team:
- Solo builder or prototype? Chroma. No account, no key, runs offline.
- Data must stay on your hardware and you have no enterprise budget? Self-hosted Chroma.
- Production RAG with no one to run databases? Pinecone. Chroma's hosted option is closing.
- Hybrid keyword plus semantic ranking? Pinecone documents it. Self-hosted Chroma doesn't, so you'd merge results in your own code. Consider the options in our Pinecone alternatives guide too.
- Currently on Chroma Cloud? Plan the migration now, using the dates above.
- Not sure you need a vector database yet? Read what RAG is and where it breaks first. Chunking and data quality usually matter more than the database.
Where Taku fits
Pinecone and Chroma are infrastructure for people building retrieval apps. If you're building one, pick one of them. Taku is for the other side of that line: an AI-native desktop workspace where you mirror an AI app, skill or workflow someone already got working, run it, remix it, and keep it, without wiring up a database yourself. Taku is in Beta, and the Mac app is available now. The free app library shows what's ready to run.
FAQ
Is Chroma Cloud shutting down?
Yes. Chroma announced on October 23, 2026 that it is winding down its cloud service. Chroma Cloud becomes read-only on November 22, 2026 and stops serving reads on December 22, 2026, per Chroma's wind-down timeline. Open-source ChromaDB continues under the Apache 2.0 licence.
Is Chroma free?
Yes, the open-source database is free under the Apache-2.0 licence, including for commercial use. You pay for the servers you run it on. Chroma's own hosted service is closing, so we don't recommend building on it.
Is Chroma or Pinecone better for RAG?
Chroma is better for prototyping, local apps and self-hosting. Pinecone suits teams that want a managed service with server-side embedding, full-text fields and dedicated read capacity. Both handle standard RAG retrieval with metadata filters.
Can I self-host Pinecone?
No. Pinecone describes itself as a managed service. The closest option is BYOC, where Pinecone runs in your own cloud account, listed as an Enterprise feature.
Can I run Pinecone locally?
Not as a real database anymore. Pinecone Local reached end of life on October 7, 2026. Pinecone's guide points to a Prism mock for request testing and a separate Pinecone project for tests that need real search.
Does Chroma support hybrid search?
Chroma's Search API supports hybrid search with reciprocal rank fusion, but its docs say it is available in Chroma Cloud only, and Chroma Cloud is closing. Self-hosted Chroma supports vector search plus $contains and $regex document filters.
How do I move from Chroma to Pinecone?
Export IDs, embeddings, documents and metadata from each Chroma collection, create a Pinecone index with a matching dimension (or re-embed), rewrite your filters, then upsert in batches or use Pinecone's bulk import from Parquet files. If your data is on Chroma Cloud, finish the export before the December 22, 2026 read cutoff.