Why Now Daily.

Published

Vector Databases: Similarity Search for AI Applications

A vector database stores embeddings with identifiers and metadata, then supports nearest-neighbor queries. Exact search compares every vector; approximate indexes trade some recall for speed.

Timeline

  1. 2016-03-30: Malkov and Yashunin submitted the HNSW paper describing hierarchical proximity graphs for approximate nearest-neighbor search.
  2. 2023: NeurIPS research examined approximate nearest-neighbor search combined with structured attribute constraints.
  3. 2025-08-25: Google updated its guidance on embedding-based candidate retrieval and approximate nearest-neighbor search.
  4. 2026-10-12: Current database documentation and primary research were reviewed for this guide.

A vector database stores numerical embeddings together with identifiers, source records and metadata, then answers similarity queries over those vectors. The label can describe a dedicated product or vector-search features inside a general database. The database does not create meaning by itself: an embedding model converts text, images or other items into vectors, while the storage and indexing layer retrieves nearby records. Keeping that distinction clear helps teams decide whether they need a separate service or can use an existing transactional system. [1][2]

A typical retrieval pipeline first divides source material into useful records or chunks, generates an embedding for each one and stores the vector beside the original content, provenance and access metadata. At query time, the same compatible embedding model converts the request into a vector, and the database returns the top k nearby candidates. Vector dimensions and model versions must match. If a model changes, old and new vectors are not automatically comparable, so migration commonly requires re-embedding and rebuilding an index. [2][5]

Similarity also depends on the distance function. Common choices include Euclidean distance, cosine distance and inner product. They can produce different rankings, especially when vectors are not normalized, so an application should use the metric recommended for its embedding model and test it on representative queries. A stored score is therefore meaningful only in the context of a particular model, normalization method and metric; it is not a portable percentage of semantic agreement. [1][2]

Exact k-nearest-neighbor search calculates the distance from a query to every stored vector and can return the true nearest records under the chosen metric. Google’s Spanner documentation describes this as higher-recall but computationally expensive at massive scale. Approximate nearest-neighbor search uses an index to avoid examining everything. It can greatly reduce latency and increase scale, but it deliberately accepts the possibility that some true neighbors will be missed. This is a recall-versus-speed choice rather than a claim that approximate results are wrong by definition. [1][2][5]

Two widely discussed index families illustrate different engineering trade-offs. HNSW builds a multilayer proximity graph and searches from coarse upper layers toward closer neighbors; its original paper describes a hierarchical graph intended to improve high-recall search performance. IVFFlat groups vectors into lists and probes only selected groups at query time. pgvector notes that HNSW generally offers a stronger speed-recall trade-off but has slower builds and higher memory use, while IVFFlat builds faster and uses less memory. Data size, update rate, latency target and available memory determine the better choice. [1][3]

Metadata filters are part of the retrieval problem, not an afterthought. Applications may need to restrict candidates by tenant, document permission, language, date, product category or jurisdiction. Research on attribute-constrained approximate search shows that simply separating vector retrieval from filtering can hurt efficiency or accuracy, because the nearest unrestricted candidates may all be removed afterward. A production design should verify how filters interact with its index and enforce authorization independently so similarity search never bypasses access rules. [1][2][4]

Vector search is a relevance signal rather than a truth engine. A nearby passage may discuss the same subject while contradicting the query, citing an old rule or containing an error. Keyword search can also outperform embeddings for exact names, codes, quotations and uncommon identifiers. Database documentation therefore supports hybrid approaches that combine vector similarity with full-text search, structured filters and reranking. Retrieval-assisted generation should retain citations and let later stages inspect the underlying records instead of treating distance as factual confidence. [1][2][5]

Teams should evaluate a vector store with their own corpus and traffic. Useful measures include recall at k against an exact baseline, end-to-end latency at realistic concurrency, filtered-query quality, index build time, memory and storage use, update visibility and deletion behavior. They should also test multilingual queries, rare terms, adversarial inputs and permission boundaries. Backups, encryption, retention and audit controls still apply because the system holds both embeddings and source metadata. A sound deployment documents the embedding version, metric, index parameters and reindexing plan so results can be reproduced and maintained. [1][2][4][5]

Sources

  1. pgvector — Open-Source Vector Similarity Search for Postgres
  2. Google Cloud — Spanner Vector Search Overview
  3. Malkov and Yashunin — Efficient and Robust Approximate Nearest Neighbor Search Using HNSW Graphs
  4. NeurIPS 2023 — Approximate Nearest Neighbor Search with Attribute Constraint
  5. Google for Developers — Retrieval with Embeddings

Related stories