What is a vector database?
A vector database stores embeddings — numeric representations of text, images or other data — and finds the ones closest to a query vector. It exists because exact nearest-neighbour search over millions of high-dimensional vectors is too slow, so these systems use approximate indexes that trade a small amount of recall for a large amount of speed. They are search infrastructure, not a replacement for a relational database.
Content is embedded by a model and indexed, commonly with HNSW, a graph structure that lets a search hop toward the query region without scanning everything. At query time the query is embedded and the index returns the k nearest vectors, usually with metadata filters applied. Recall depends on index parameters, and every system exposes a speed-versus-recall dial. Many teams add a re-ranking model over the top results, because embedding similarity alone is a coarse relevance signal.
A documentation search embeds 400,000 paragraphs, retrieves 50 candidates in a few milliseconds, re-ranks them to 5, and passes those to the model.
Vector search is the retrieval half of most production AI systems. Choosing between a dedicated service and a vector extension on an existing database is mostly an operational decision — scale, filtering needs and who runs it — not a quality one at modest corpus sizes.
- That results are exact. Approximate indexes miss neighbours by design.
- That you need a dedicated vector database. Postgres with pgvector handles many workloads.
- Vendor benchmarks use datasets and parameters chosen by the vendor; recall and latency rarely transfer.
- Cost comparisons shift quickly as pricing models change.