A vector store is an index, not a database

#The word database does a lot of damage

Calling something a vector database creates an expectation of durability, transactions and consistency with the rest of your data. What you have is an index over embeddings, with the same relationship to your source data that a search index has.

Treating it as the source of truth is how teams end up unable to rebuild after a corruption, because the embeddings are there and the text they came from is not.

#Approximate means approximate

Exact nearest neighbour search over a large collection is expensive, so production systems use approximate methods. Hierarchical navigable small world graphs are the common choice and they are good [1], and the operative word is approximate.

Recall is a parameter. Higher recall costs query time and memory. The default in most libraries is a compromise chosen by the library author for a benchmark, not for your data, and it is worth measuring what yours actually gives you.

The failure mode is quiet. A query returns plausible results that are missing the best match, and nothing in the response says so. Quantisation makes this more pronounced, and it is often enabled by default because it saves substantial memory [2].

#The update cost

Graph-based indexes are built for read performance and updates disturb the structure. A high update rate degrades the index over time, and periodic rebuilds are part of operating one rather than an exceptional event.

That has a direct architectural consequence: if the index can be rebuilt from source data, a degradation is an inconvenience, and if it cannot, it is data loss. This is the same argument for keeping derived data derived that applies to any search index [3].

#Embeddings have a version

The embedding model is part of the index. Change the model and every stored vector is in a different space, so old and new vectors cannot be compared meaningfully.

Upgrading means re-embedding the corpus, which for a large collection is a cost and a scheduling problem. Recording the model identifier and version alongside every vector is cheap and it is the only thing that makes a mixed-state index detectable rather than silently wrong.

#What I would recommend

Keep the source text and its metadata in your primary store. Treat the vector index as a projection that can be dropped and rebuilt. Record the embedding model version with every vector. Measure recall on your own data rather than trusting a default.

If your corpus is modest, an extension to the database you already run is very likely enough, and it brings transactions and one operational unit instead of two [4].