When you search on Google, the engine does not compare individual words: it compares meanings. Behind that ability sits a piece of software that has moved from the lab to production in just a few years: the vector database. This article explains how it turns text into coordinates and why that changes the way we search.
From text to numbers: the embedding
An embedding is a representation of a piece of data (a word, a sentence, an image) as a vector of real numbers, usually hundreds or thousands of dimensions. The core idea is that similar meanings end up close together in that space: “cat” and “feline” point to neighboring regions, while “cat” and “toaster” stay far apart.
Those vectors are not hand-crafted. They are produced by a neural network trained on huge text corpora. Modern models, such as those based on the transformer architecture (the same kind of network behind large language models), learn to project each sentence into a space where distance reflects semantic relatedness.
The metric that decides closeness: cosine
To tell whether two embeddings are similar, systems almost always use cosine similarity: the cosine of the angle between the two vectors. If two vectors point in the same direction, the cosine is 1 (maximum similarity); if they are perpendicular, 0; if they point in opposite directions, -1.
This metric is cheap to compute and, unlike Euclidean distance, is not distorted by the length of the vector. That is why it is the standard choice in semantic search engines.
The problem: searching millions of vectors
Here is the technical challenge. If you have a million documents, each with a 768-dimensional embedding, finding the one most similar to a query by brute force requires comparing the query against all one million vectors. That is an O(n) cost per search, unworkable at scale.
Vector databases solve this with approximate nearest neighbor (ANN) indexes. They do not return the exact neighbor, but a very close one, in exchange for enormous speed.
The ANN indexes: HNSW and IVF
The most popular index is HNSW (Hierarchical Navigable Small World), a layered graph. The top layer has few, highly connected nodes; the lower layers have progressively more. The search starts at the top and “descends” through the layers, hopping from node to node toward the most promising region. It is like moving across a map with highways: first you speed along the main roads, then you fine-tune on the streets.
Another family is IVF (Inverted File Index), which groups vectors into clusters using k-means. The search only examines the clusters closest to the query, not all vectors. Many systems combine IVF with product quantization (PQ), which compresses each vector so millions fit in memory.
Why is a SQL database not enough?
Relational databases index with B+ trees or hashes, designed to look up an exact value or a range. They cannot answer “give me the most similar to this vector”. You could store embeddings as columns, but similarity search would still be a full scan. The vector database provides exactly the specialized index that is missing.
Real use cases: RAG, recommendation and deduplication
The best-known use today is retrieval-augmented generation (RAG): before a language model answers, a system searches a vector database for the most relevant document fragments to the question and passes them as context. That way the model answers with up-to-date information without being retrained.
They are also used for recommendation (finding similar products or articles), image search by visual similarity, duplicate detection, and clustering documents by topic.
In short
A vector database turns the problem of “searching by meaning” into a geometry problem: represent each item as a point and find the closest points. Embeddings provide the representation and ANN indexes provide the speed. Together, they let a machine understand that “how to fix a dripping faucet” and “repair a water leak in the bathroom” are, at heart, the same question.
