RAG and Knowledge Engineering
Vector Database — Stack
Vector database › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
Judge on behaviour at your corpus size with your constraint pattern, because almost everything here looks equivalent at a million vectors and diverges sharply above that.
- Measured recall at your operating point, against exhaustive search on a sample of your own corpus — not the vendor's figure, and re-measured after every parameter change.
- Constrained-search semantics. Whether attribute constraints are applied before, during or after the approximate search, and what happens when the constraint is highly selective. Ask for the behaviour, not the feature checkbox.
- Update and delete behaviour. In-place update support, tombstone accumulation, compaction triggers, and how recall and latency move between compactions.
- Memory and storage footprint per vector at your dimension, with and without quantisation, including the index overhead rather than only the raw vectors.
- Build and rebuild cost. How long a full index build takes, whether it can run while serving, and whether an alias or equivalent indirection exists for a swap.
- Multi-tenancy model. Collection limits, per-partition isolation, and whether one tenant's volume can degrade another's latency.
- Lexical or sparse retrieval in the same engine, which decides whether hybrid retrieval is one system or two.
- Consistency and durability. Write visibility guarantees, replication semantics, and what a node loss costs in rebuild time.
- Operational maturity. Backup and restore of an index, observability of recall-adjacent signals, and upgrade paths that do not require a rebuild.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Dedicated vector engines (Qdrant, Weaviate, Milvus, Vespa) | Large corpora needing constrained search, hybrid retrieval and tunable index parameters | Another stateful system to operate; constrained-search behaviour differs substantially between them |
| Managed vector services (Pinecone, Zilliz Cloud, Vertex AI Vector Search, Azure AI Search) | Teams that want index tuning and compaction to be somebody else's job | Index internals and recall are opaque; cost scales with stored vectors and with query volume |
| Vector extensions to relational databases (pgvector, pgvectorscale, Oracle and SQL Server vector types) | Corpora where the attributes and the documents already live in the database | Index build and memory behaviour are bounded by the database's; very large corpora outgrow this before the SQL convenience stops being worth it |
| Search engines with vector support (Elasticsearch, OpenSearch, Apache Solr) | Estates that already run the engine and need lexical and vector retrieval together | Vector support is an addition to a document store; per-shard index sizing and heap pressure need attention |
| Embedded and library indexes (FAISS, hnswlib, Annoy, ScaNN, usearch) | Fixed corpora, offline evaluation, and the baseline you measure recall against | No durability, no constrained search and no update story unless you build them |
| Disk-resident index designs (DiskANN-style implementations) | Very large corpora where keeping the index in memory is the cost driver | Latency depends on storage characteristics; build times are long and parameters are unforgiving |
| Object-storage-backed serverless vector stores | Intermittent query volumes and large, rarely queried corpora | Cold-start latency on first query; unsuited to interactive paths with a tight budget |