Vector database definition

A vector database stores numerical representations of meaning and retrieves records by how close they sit to a query in that number space, so a search for "login process" can return a document titled "authentication flow." In Sanity, those vectors live beside the content they describe as dataset embeddings in the Content Lake, queried through the `text::semanticSimilarity()` GROQ function, so one query can filter on structure and rank by meaning without a second store to keep in sync.

How does a vector database work?

A vector database works in three steps: an embedding model turns each piece of content into a vector, the database indexes those vectors by position in space, and the query is embedded the same way so the database can return the nearest neighbors.

The first step produces an embedding, a list of numbers where semantically close items land close together. Sanity's documentation gives a clean illustration: "authentication flow" and "login process" end up near each other even though they share no words, while "authentication flow" and "authentic basketball jersey" end up far apart.

Closeness is measured with a distance metric. Three in common use are cosine similarity, dot product, and Euclidean distance. Comparing a query against every stored vector one by one gets too slow once a collection is large, so vector databases rely on approximate nearest neighbor (ANN) indexes, which trade a small amount of exactness for a large gain in speed. The most widely deployed of these is HNSW, described by Malkov and Yashunin in a 2016 arXiv preprint (1603.09320) and later published in IEEE TPAMI in 2020. IVF, product quantization, and locality-sensitive hashing are other techniques in the same family.

Production vector databases also store scalar metadata next to each vector, such as category, tenant, or date, so a query can be constrained rather than being pure similarity.

What is the difference between a vector database and a traditional database?

The difference between a vector database and a traditional relational database is the retrieval mode: a relational database matches exact values and range predicates, while a vector database ranks records by geometric closeness to a query vector.

A keyword query for "smartphone" in a relational or full-text system returns rows containing that token. A vector query for the same phrase can surface records that say "cellphone" or "mobile device," because the match happens in the embedding space, not at the level of characters. IBM draws exactly this contrast in its explainer on vector databases.

This is a difference in how retrieval works, not a replacement claim. Joins, exact predicates, aggregation, and transactional guarantees are all things similarity search does not do. Most real systems need both, which is why vector search shows up as a capability inside a general-purpose store rather than only as a separate product.

Do you need a dedicated vector database?

You do not always need a dedicated vector database, because vector search is now available as a feature of systems that already hold your data. Postgres with the pgvector extension, MongoDB Atlas Vector Search, Elasticsearch kNN, and Sanity's dataset embeddings all add similarity search to an existing store. IBM makes the same distinction, separating dedicated vector databases from vector extensions such as pgvector.

A related distinction is worth keeping straight: a vector database is not a vector search library. Libraries such as Faiss, ScaNN, Annoy, and hnswlib give you an in-memory index and a nearest neighbor algorithm. A vector database adds the properties that make a database a database: durability, incremental inserts, updates and deletes on individual vectors, metadata filtering, replication, backups, and access control. Libraries are typically rebuilt or checkpointed rather than mutated in place.

The practical question is usually about synchronization rather than algorithms. The standard architecture keeps the source of truth in one system and copies of its embeddings in another, which means a sync job that can fall behind. When the vectors live with the content, that job disappears. In Sanity, enabling embeddings on a dataset is a single CLI operation, embeddings are recomputed asynchronously when a document changes (normally in under a minute, per Sanity's documentation, though large or frequent updates can take longer), and the managed embedding model triggers an automatic recompute if it is updated.

What is a vector database used for?

A vector database is used wherever the useful notion of a match is similarity rather than equality: semantic search over documents, recommendation, deduplication and near-duplicate detection, image and audio search, anomaly detection, and retrieval for AI applications.

The best-known use is retrieval-augmented generation (RAG), the pattern where a system retrieves relevant material and places it in a language model's context before generating an answer. It helps to keep the layers separate. RAG is an application pattern, a vector database is one possible retrieval backend for it, and semantic search is the behavior a vector database can implement. RAG can also be built on keyword search, structured queries, or a mix of the two, with no vector database involved.

One boundary is often skipped: the embedding model is not the database. The model produces the vectors, and the database stores and searches them. Swapping models invalidates every stored vector and requires re-embedding the whole collection, which is why the model choice is an architectural commitment, not just a setting.

What are the limitations of vector search?

The main limitation of vector search is not filtering, but ranking. A similarity query orders everything by closeness to the query vector. It has no notion of "must be in stock" or "must be under $150." Structural constraints have to come from a predicate, applied before or alongside the ranking.

This shows up quickly in practice. Vector search handles a fuzzy request like "something like a trail runner" well and falls over on a structural one like "trail runners under $150, in stock at the Portland warehouse, men's size 11." The reliable pattern is to narrow the candidate set with a filter first, then rank what is left.

Pure similarity also underperforms hybrid retrieval. In Anthropic's contextual retrieval experiments published in September 2024, contextual embeddings cut the top-20 retrieval failure rate by 35%, adding contextual BM25 keyword scoring took the reduction to 49%, and adding a reranking stage reached 67%, moving failure rate from 5.7% to 1.9% (measured as 1 minus recall@20). Having embeddings is an ingredient, not a retrieval strategy.

This is where the shape of Sanity matters. As the Content Operating System for the AI era, Sanity keeps structured content and its embeddings in the same place, and GROQ enforces the distinction in the language itself: `text::semanticSimilarity()` is only valid as an argument to `score()`, so filters stay filters and similarity stays ranking. Dataset embeddings are available on all plans, generation and updates are included at no additional cost, and semantic queries count against an organization's monthly semantic search quota.

Last updated: September 11, 2026