When should a LlamaIndex app move off SimpleVectorStore to Chroma, Pinecone or Weaviate?

## What the default actually is `SimpleVectorStore` holds embeddings in memory and compares the query vector against every stored vector. There is no index structure and no approximation, so results are exact — which is a genuine advantage while you are still tuning chunking and prompts, because retrieval quality is not confounded by an approximate search. It serialises to JSON with the rest of the storage context, which means a save rewrites the file rather than appending. ## The four signals to move **Memory.** The whole index lives in the process. Once vectors plus node text no longer fit comfortably alongside the application, you are choosing between a bigger instance forever and a store designed to hold this data. **Sharing.** With several replicas, each one either loads its own copy of the index at startup — slow boots, duplicated memory, and a window where replicas disagree after a rebuild — or they all point at one store. The second is the only shape that scales operationally. **Write pattern.** Rewriting a JSON file on every change is fine for a nightly rebuild and untenable for continuous ingestion. External stores accept upserts and deletes per record. **Durability and concurrency.** In-memory means a crash loses everything since the last persist, and nothing coordinates a writer against readers. Once freshness has an SLA, that is not acceptable. Search latency is often assumed to be the trigger, and it usually is not the first one — a brute-force scan over a modest corpus is quick. It becomes the trigger once the corpus is large enough that a linear scan per query dominates response time. ## What changes in the code Surprisingly little. You construct the integration's store object, wrap it in a storage context, and build as usual: ``` storage_context = StorageContext.from_defaults(vector_store=store) index = VectorStoreIndex.from_documents(documents, storage_context=storage_context) ``` Later processes attach with `VectorStoreIndex.from_vector_store(store)` and skip the build entirely. Retrieval code is unchanged, which is the point of the abstraction. ## What does not port cleanly The abstraction is not perfectly uniform, and pretending otherwise is what makes migrations painful: - **Metadata filtering.** All integrations accept filters, but the supported operators and how they perform differ by backend, so a filter-heavy retrieval design tuned on one store can behave differently on another. - **Hybrid and sparse search.** Some backends support it natively and expose it through their integration; others do not, so a design that depends on it constrains your choice of store. - **Docstore semantics.** Most integrations keep node text alongside the vector, so `from_vector_store()` alone answers queries. But without a docstore you lose document hashes, and with them refresh-by-hash and delete-by-document. Decide early whether the docstore is persisted and shared too. - **Approximate search.** External stores generally use an ANN index, so results are approximate and tunable. Quality differences you attribute to your chunking may in fact be recall differences from index parameters. ## Framing the decision at a lead level The question behind the question is what you are willing to operate. A managed service converts the problem into a bill and a vendor dependency; a self-hosted store converts it into capacity, backups and upgrades your team owns; an embedded store keeps the data local and single-writer, which is a real fit for a single-node service and a dead end for a fleet. The strongest answer names the trigger you would act on, states that the retrieval code is portable while the operational commitment is not, and keeps the choice reversible by not letting store-specific features leak into the application until they have earned it.