A team needs vector search. When is a dedicated vector database justified over adding vector search to an existing store?

When the existing store is sufficient

For most applications, it is. Postgres with a vector extension, or an existing search engine with vector support, handles millions of vectors with adequate latency — and it brings enormous advantages: one system to operate, transactional consistency between the vectors and the records they describe, and filtering and joining against the same data in one query.

That last point is decisive more often than it is credited. Real retrieval almost always needs metadata filtering — tenant, category, language, date, permissions — and doing it in the same store is far simpler than coordinating a vector store with a relational one.

When a dedicated store is justified

• Scale beyond what the general-purpose store handles well, which is a real threshold and is higher than most teams assume.
• Query latency requirements that the general store cannot meet at that scale.
• Index update patterns that the general store handles poorly — very high write rates with immediate searchability.
• Specific algorithmic requirements the general store does not support.

The costs of a separate store

• A second system to operate, with its own failure modes, backups, upgrades and on-call knowledge.
• Consistency between the vector index and the source of truth, which becomes a synchronisation problem with all the usual failure modes — and a vector referencing a deleted record is a correctness and sometimes a privacy issue.
• Filtering that must be coordinated across two systems, which is either slow, incorrect, or requires duplicating metadata.

The judgement

Start with the existing store and move when a measured limit is reached. The threshold should be a number — query latency at the required scale, or index size — not an assessment that a specialised tool would be better in principle. It almost always would be, and that is not sufficient.

And note that retrieval quality is dominated by chunking, embedding choice, hybrid search and reranking, not by the vector store. Teams that change stores hoping to improve quality are usually optimising the component that was not the problem.