Best practices for handling huge document updates in Chroma DB without downtime?

All answers to this question.

The most reliable way to handle this in Chroma is to create a new collection with a timestamped name (e.g., knowledge_base_v2). You can ingest all your data into this new collection in the background. Once the indexing is complete and the HNSW index is fully built, you just update a pointer in your application code or a simple Redis key to point to the new collection name. This gives you an instantaneous switchover with zero downtime. I’ve been using this strategy for a news-aggregator bot throughout 2025, and it allows us to refresh our entire index every few hours without the users ever noticing a glitch.

   Answered 2025-03-28 by Sharon Martinez

Does creating a second collection double my RAM requirements since both indices might be loaded at once?

   Answered 2025-03-30 by Matthew Turner

• Temporary doubling of RAM is the trade-off for zero downtime, Matthew. However, you can mitigate this by running the indexing on a separate "worker" instance that isn't serving user queries. Once the index is saved to persistent storage (like an S3 bucket or a shared volume), your production Chroma DB instance can simply pull the new files and swap them in. I implemented this "detached indexing" pattern in May 2024 for a large enterprise client, and it kept the production environment's memory usage extremely stable while handling million-vector updates.

     Commented 2025-04-02 by Jason Phillips

Chroma’s persistent storage makes this much easier than it used to be. You can just point the new instance to the updated data folder.

   Answered 2025-04-03 by Michelle Lewis

• Good point, Michelle. The decoupling of the storage layer in Chroma DB really helps when you're trying to manage these heavy-duty update cycles in a production environment.

     Commented 2025-04-05 by Joshua Parker