Vector Databases

Vector Databases

Definition: Databases purpose-built to store, index, and query high-dimensional vector embeddings, numerical representations of meaning produced by machine learning models, so that “find items similar to this one” runs fast at scale.

Unlike a traditional index, which speeds up exact-match or range lookups, a vector index answers a fundamentally different question: “which of these millions of items is mathematically closest to this one,” a query relational engines were never designed to answer efficiently.

How It Works

  • Embedding: a model (text, image, or audio encoder) converts an object into a fixed-length vector, commonly 384 to 1536 dimensions, where geometric closeness in that vector space corresponds to semantic similarity.
  • Storage: the database stores each vector alongside its source object (or a reference to it) and any metadata used for filtering (category, timestamp, owner).
  • ANN indexing: exact nearest-neighbor search is O(N) per query, too slow past a few hundred thousand vectors. Approximate Nearest Neighbor (ANN) algorithms, most commonly HNSW (Hierarchical Navigable Small World graphs) or IVF (Inverted File index), trade a small amount of recall for a massive speedup.
  • Distance metric: similarity is computed with cosine similarity, dot product, or Euclidean (L2) distance, chosen to match how the embedding model was trained, using the wrong metric silently degrades result quality without erroring.
  • top-k retrieval: a query returns not one answer but the k closest vectors (k=5, k=20, etc.), ranked by distance/similarity score, which then typically get passed to a re-ranking step or directly into an LLM’s context window.
  • Re-ranking: a slower, more accurate model scores the top-k candidates returned by the fast ANN search, refining the final order. This two-stage pattern, cheap broad retrieval followed by expensive precise ranking, appears throughout information retrieval, not just vector search.

Under the Hood

The pipeline from raw input to returned nearest neighbors, and the layered graph structure HNSW searches through:

Worked example 1: HNSW search descent

  • Given: a query vector for “how does WAL work,” an HNSW index with 3 layers built over 10 million document-chunk embeddings.
  • Step: search starts at a fixed entry point in the sparsest top layer (Layer 2) and greedily moves to whichever neighbor is closer to the query vector, jumping long distances cheaply since this layer has few nodes.
  • Step: once no neighbor in Layer 2 is closer, descend to Layer 1, repeat the greedy search among its denser connections, then descend again to Layer 0, the densest layer, containing every vector.
  • Answer: the final local search in Layer 0 returns the true nearest neighbors with high probability, in roughly O(log N) hops instead of scanning all 10 million vectors, this is the core trick that makes ANN “approximate but fast.”

Worked example 2: exact kNN vs ANN at scale

  • Given: a product catalog with 50 million item embeddings, a user searches for visually similar items.
  • Step: exact k-Nearest Neighbors compares the query vector against all 50 million stored vectors, computing a distance for each, an O(N) operation per query.
  • Step: at, say, 50 microseconds per comparison, that’s 2.5 seconds of raw compute per query, before even accounting for memory bandwidth, unacceptable for an interactive search bar.
  • Answer: an HNSW or IVF index cuts this to single-digit milliseconds by only comparing against a small, well-chosen subset of vectors, accepting roughly 95-99% recall (occasionally missing the true single best match) in exchange for a 100-1000x speedup.

Worked example 3: metadata-filtered search

  • Given: SELECT the 10 most similar support articles to a query, but only articles tagged product = 'billing'.
  • Step: pre-filtering (apply the metadata filter first, then search only the ANN index over the reduced set) can miss the ANN index structure’s graph connectivity if the filtered set is a small, scattered fraction of the whole index.
  • Step: post-filtering (run the full ANN search, then discard non-matching results) risks returning fewer than 10 results if too many top matches get filtered out.
  • Answer: production vector databases (Pinecone, Weaviate, pgvector with partial indexes) implement hybrid filtering strategies, filtering during graph traversal itself, to avoid both failure modes, this is a genuinely hard, actively-developed part of vector search engineering.

Worked example 4: choosing dimensionality and its cost

  • Given: switching an application’s embedding model from a 384-dimension model to a 1536-dimension model for better semantic accuracy, across 20 million stored documents.
  • Step: raw vector storage cost scales roughly linearly with dimensions, 20M × 384 × 4 bytes (float32) ≈ 30.7 GB versus 20M × 1536 × 4 bytes ≈ 122.9 GB, a 4x storage increase.
  • Step: HNSW graph construction and search time also scale with dimensionality, since every distance computation now touches 4x the numbers, and higher-dimensional graphs are typically slower to traverse per hop.
  • Answer: the accuracy gain from more dimensions has to be weighed against a real, multi-times increase in memory footprint and query latency, this is why techniques like product quantization (compressing vectors into smaller approximate codes) exist, to claw back some of that cost.

Index Types Compared

  • HNSW: builds a multi-layer navigable graph, excellent query speed and recall, but memory-hungry (the full graph typically lives in RAM) and slower to build/update than IVF.
  • IVF (Inverted File Index): clusters vectors into buckets (“Voronoi cells”) via k-means, a query only searches the nearest few buckets. Faster to build and more memory-efficient than HNSW, but generally lower recall at the same speed unless combined with re-ranking.
  • IVF-PQ: IVF combined with Product Quantization, compressing each vector into a small code, dramatically reducing memory at some further recall cost, common for billion-scale datasets where storing full-precision vectors is impractical.
  • Flat (brute-force): no index at all, exact search. Only viable at small scale or as a ground-truth baseline to measure an ANN index’s recall against.

Recall, the fraction of true nearest neighbors an ANN search actually finds, is the metric that ties all of these together. A well-tuned HNSW index commonly achieves 95-99% recall at a fraction of brute-force’s latency; pushing recall closer to 100% by widening the search (larger ef_search/nprobe) trades speed back for accuracy, there is no free lunch, only where on that curve a given application needs to sit.

Why It Matters

Vector databases are the retrieval layer behind Retrieval-Augmented Generation: they let an LLM-powered application find the handful of relevant documents out of millions before generating an answer, grounding output in real data instead of relying purely on the model’s training-time knowledge. The same mechanism powers semantic search, recommendation systems, image similarity search, and deduplication, anywhere “similar meaning” matters more than exact keyword match.

  • It closes the gap between “the model knows about this generally” and “the model has this specific document in front of it right now,” which is what makes grounded, citable answers possible instead of confident guesses.
  • It lets applications search meaning rather than exact words, a query for “cancel my membership” can retrieve a document titled “how to close your account” even though no words overlap.
  • It scales a fundamentally hard problem, exact similarity search is expensive, into something that runs interactively, which is what makes real-time semantic search products possible at all.

Common Pitfalls

  • Using exact kNN search on a large dataset, resulting in unacceptably slow O(N) query latency instead of an ANN index.
  • Mismatching the distance metric against what the embedding model was trained with, cosine similarity on a model trained for dot product similarity gives plausible-looking but subtly wrong rankings.
  • Ignoring recall trade-offs: HNSW’s ef_search and IVF’s nprobe parameters trade query speed for accuracy, tuning them purely for latency without measuring recall against a labeled test set produces confidently wrong results.
  • Re-embedding a large corpus with a new model version but forgetting old and new embeddings from different model versions are not comparable in the same vector space, they must be re-indexed together, not mixed.
  • Treating a vector database as a replacement for a relational database, rather than a complementary index, most production systems still need exact filtering, transactions, and joins that vector search alone doesn’t provide.
  • Chunking source documents too large or too small before embedding, oversized chunks dilute a specific fact among unrelated text, hurting retrieval precision; undersized chunks lose surrounding context, hurting relevance even when the exact match is retrieved.
  • Never measuring recall against a labeled ground-truth set, tuning purely by eyeballing top results looks fine on easy queries and quietly fails on harder ones where the true best match sits outside the approximate search’s candidate set.
  • Forgetting embeddings need periodic refresh. A model deprecation or a meaningfully improved successor model means re-embedding the whole corpus eventually, budget for that as an ongoing cost, not a one-time setup step.

Pure vector similarity search can miss exact matches that keyword search would catch immediately, searching for an exact product SKU or error code against semantic embeddings often returns plausible-but-wrong neighbors instead of the literal match. Hybrid search combines a traditional keyword/full-text index (BM25 or similar) with vector similarity, then merges the two ranked result sets, commonly via Reciprocal Rank Fusion, to get both semantic relevance and exact-match precision in one query. Most production vector databases (Weaviate, Elasticsearch, Pinecone) now support this as a first-class query mode rather than something built by hand.

Comparison

The right column below is doing the real work, the systems in this table overlap heavily in raw capability, and the deciding factor in practice is almost always “what does this workload need alongside vector search.”

SystemApproachBest for
Pinecone, Milvus, WeaviateDedicated vector database, ANN-first architectureHigh-scale, dedicated semantic search / RAG workloads
pgvector (PostgreSQL extension)Vector indexing added to a general-purpose relational databaseModerate scale, when you want vectors alongside relational data and joins
Elasticsearch / OpenSearch (vector fields)Full-text search engine with added ANN supportHybrid keyword + semantic search
Exact kNN (brute force)Linear scan, no indexSmall datasets (thousands of vectors) or ground-truth evaluation

None of these are strictly better across the board, the decision hinges on scale, update frequency, and whether vectors need to coexist with relational data and transactional guarantees. A team already running PostgreSQL for everything else often starts with pgvector precisely to avoid operating a second database system, then migrates to a dedicated engine only once scale or latency requirements genuinely demand it.

Example

Pinecone and Milvus are dedicated vector databases built ANN-first, offering managed HNSW/IVF indexing, metadata filtering, and horizontal scaling as core features. pgvector instead adds vector columns and index types (ivfflat, hnsw) directly to PostgreSQL, letting a team keep embeddings in the same database as their relational data, and query both in a single SQL statement, a common choice when the vector workload doesn’t yet justify a separate specialized system.

Weaviate and Elasticsearch both bolt vector search onto systems that started as document/full-text search engines, which makes them a natural fit when hybrid keyword-plus-semantic search matters more than raw ANN throughput. The choice among these systems usually comes down to how tightly the vector workload needs to integrate with existing relational or search infrastructure, versus how much scale and specialized tuning the workload demands.

Scaling Considerations

  • Horizontal sharding: past tens of millions of vectors, a single HNSW graph in one machine’s memory becomes impractical, dedicated systems shard the index across nodes and merge candidate results at query time.
  • Index build time: HNSW graphs are expensive to build incrementally at scale, bulk-loading a fresh corpus is typically far faster than inserting vectors one at a time, since batch construction can parallelize graph-linking work.
  • Update-heavy workloads: ANN indexes generally favor read-heavy, append-mostly workloads. Frequent deletes/updates (common in HNSW) require either periodic rebuilds or tombstone-and-compact strategies similar in spirit to an LSM tree’s compaction.
  • Cost model: managed vector databases typically bill by stored vector count, dimensions, and query volume together, which is why dimensionality reduction and quantization decisions are cost decisions, not just performance ones.

Referenced by

Dig deeper