Vector search is an indexing decision, not a database purchase

Strip the category marketing away and vector search is an index: a data structure that trades exactness for speed on nearest-neighbour queries, the way a B-tree trades space for ordered lookups. The core algorithms — HNSW's navigable graph, IVF's clustered inverted lists, product quantization for compression — are library code; FAISS has shipped them for years, ScaNN and ANNOY likewise. What the "vector database" category added was operations around that index. That's genuinely valuable, but it means the purchase decision is an indexing-and-operations decision, and it should be evaluated with the same questions you'd ask of any index — not with the reflex that a new workload demands a new database.

The questions are concrete. Which structure fits your recall/latency/memory point — HNSW's memory-resident graph for high recall at speed, IVF-PQ when the corpus won't fit in RAM uncompressed? How does filtering work, since "nearest neighbours where tenant_id = X and date > Y" is the real production query, and pre-filtering, post-filtering, and in-graph filtering give meaningfully different recall and cost profiles? How is tenancy isolated — collection-per-tenant silos, payload-based partitioning with a group filter, Pinecone-style namespaces, Weaviate's per-class tenant shards? Get that one wrong and you meet the pool-model failure mode: tenant leakage through an unguarded query, which is why mature setups inject mandatory tenant filters at the retrieval layer rather than trusting callers. None of these are "which vendor" questions. They're index-design questions that every vendor answer merely packages.

The index is coming to the data

Meanwhile the databases you already run grew the index. pgvector puts HNSW inside Postgres; Neo4j ships a native vector index alongside graph traversal; DuckDB, the warehouses, and even Oracle's autonomous database now do vector search next to the relational data — Oracle's pitch is explicitly an integration-tax argument: keeping vectors where the business data lives avoids a second system, a second security model, and a sync pipeline. That last cost is the one buyers underweight. Embeddings are derived data; the moment they live in a separate store, you own a pipeline keeping them consistent with their sources, plus embedding-model governance on top — switch models and the entire index must be rebuilt, so the store must version model identity and detect mismatch at query time. A dedicated database doesn't remove that work; it adds a network boundary to it.

The honest counter-case: sometimes the dedicated system is right. At billions of vectors with strict latency SLOs, a distributed engine like Milvus is built for exactly that shape, and a managed service like Pinecone is a rational buy when vector search is your core workload and you'd rather rent the operations than build them. If retrieval is the product, buy the specialist. But that's precisely evaluating it as an indexing-and-operations decision — workload size, recall target, filter patterns, tenancy model, ops capacity — rather than as a category checkbox. Most teams running a few million vectors behind a RAG feature will find their existing Postgres, their document store, or their lakehouse already does this well enough, one CREATE INDEX away.

The pattern generalises. Retrieval quality is mostly determined above the index — embedding choice, chunking, the pipeline feeding it — and read-path design matters more than storage branding. Buy indexes on their merits. Be suspicious when an index is sold as a category.