A platform needs similarity search over a large and growing corpus. What decides between a dedicated vector database, a vector extension to an existing store, and a search engine with vector support?

The default that is usually right

A vector extension to a store you already operate. For most workloads this is sufficient, and it avoids the cost that dominates the decision: every additional stateful system is a new place data can disagree, plus backup, failover, monitoring, patching, on-call expertise and a local development dependency.

It also keeps the vectors alongside the metadata they must be filtered by, which is the requirement that most often breaks naive designs.

What justifies a dedicated system

• Scale beyond what the existing store serves acceptably, measured rather than assumed.
• Query latency requirements the existing store cannot meet at that corpus size.
• High write throughput with immediate searchability, which some index structures handle poorly.
• Very high dimensionality or specialised index configuration requirements.

What justifies a search engine with vector support

Hybrid retrieval as a first-class need. Pure semantic search misses exact identifiers, error codes, product names and acronyms — which is precisely what real queries contain. A search engine gives keyword and semantic retrieval in one system with one relevance model, rather than two systems and a fusion step.

For a corpus of documents, code or products, this is frequently the right answer and it is under-considered because vector search is the newer idea.

The requirement that decides more designs than recall does

Filtered search. Real queries are almost never "find similar" — they are "find similar within this tenant, of this type, created after this date, that this user may see". Systems differ enormously in how well they combine filtering with approximate nearest-neighbour search: filtering after retrieval returns too few results, and filtering before it can defeat the index entirely.

Benchmark on your filtered workload, not on recall. A benchmark measuring unfiltered recall answers a question you do not have.

The properties to verify before committing

• Filtered query performance at realistic selectivity.
• Index rebuild cost, since embedding model changes require re-embedding and re-indexing the entire corpus — an operation that will happen and must be plannable.
• Deletion and update behaviour, particularly whether deletes are immediate or deferred to compaction.
• Consistency between the vector store and the source of truth, which requires reconciliation like any derived store.