A specialized database designed to store, manage, and search large quantities of embeddings (high-dimensional vectors).
A vector database stores embeddings and answers nearest-neighbor queries fast using approximate indexes (HNSW and similar) that trade tiny recall losses for orders-of-magnitude speed at scale. Production-grade systems pair vectors with metadata filtering (date, source, permissions), hybrid keyword+vector search, and CRUD pipelines for keeping indexes synchronized with source content.
Vector search is the retrieval engine behind RAG, semantic search, and agent memory, which makes the vector database a standard tier of the 2026 AI stack, alongside the application database. Choice and tuning here (index parameters, filters, hybrid weighting) directly set answer quality and latency for most enterprise AI products.
Postgres with pgvector comfortably serves many workloads into the millions of vectors and keeps your stack simple. Dedicated engines earn their place at larger scale, high query throughput, or when you need advanced hybrid search and multi-tenant isolation features.
Index structures that find near-closest vectors without scanning everything, trading a small recall loss for massive speed. Parameters let you tune the recall/latency balance per application.
Vectors capture meaning but can miss exact identifiers, codes, and rare names that keyword search nails. Hybrid retrieval with a reranker on top consistently outperforms either alone on enterprise corpora.