What is the difference between an embedding and a vector database?

An embedding is the numerical representation produced by a model. A vector database is infrastructure for storing those vectors, associating them with records and metadata, indexing them, and searching for nearby vectors efficiently. The model defines the geometry of meaning; the database makes that geometry usable at application scale.

Which similarity metric should I use?

It depends on the embedding model and how its vectors were trained. Cosine similarity is common when direction matters more than magnitude, dot product is common for some retrieval-trained models, and Euclidean distance measures straight-line distance. Do not choose by habit alone; use the metric recommended for the model and validate it on real queries.

Are embeddings a replacement for keyword search?

Not always. Embeddings are strong when meaning differs from wording, but keyword search is often better for exact identifiers, error codes, names, and rare terms. Many production systems use hybrid retrieval: lexical search for exact signals, vector search for semantic matches, then filtering and reranking to produce the final order.

Why do vector search results sometimes look wrong?

The system is returning items that are close under the model’s learned geometry, not items a human has explicitly judged relevant. Bad chunking, mismatched embedding models, the wrong distance metric, weak metadata filters, or an approximate index with low recall can all hurt results. Evaluation needs realistic queries and relevance judgements, not just inspection of a few examples.

Embeddings and Vector Search

Embeddings and vector search are a retrieval technique where data is converted into numerical vectors and searched by geometric closeness rather than exact terms. An embedding model places semantically similar text, images, audio, or code near each other, then a vector index finds the stored items closest to a query vector.

The problem is that exact matching is often the wrong shape for retrieval. Users ask questions in different words from the source material, documents use synonyms, and useful context may share meaning without sharing tokens. Keyword search can still be valuable, but it cannot reliably answer “what is this about?” across messy language, code, images, or mixed data. Embeddings make retrieval depend on learned similarity, not just literal overlap.

An embedding model takes an item, such as a paragraph or image, and outputs a list of numbers. That list is a point in a high-dimensional space. At query time, the query is embedded with the same compatible model, then compared with stored vectors using cosine similarity, dot product, or Euclidean distance. A vector database stores the vectors with record identifiers and metadata, and returns nearest neighbours according to the chosen distance calculation.

At scale, comparing a query with every stored vector can be too slow, so systems usually use approximate nearest neighbour indexes. These indexes organise vectors so the search can skip most comparisons, accepting that it may miss some true nearest items. That is where recall matters: higher recall means fewer missed relevant results, but usually costs more memory, compute, or latency. Precision and ranking then decide whether the returned candidates are actually useful.

Engineers meet embeddings and vector search in semantic search, recommendations, duplicate detection, clustering, and retrieval-augmented generation. A common production pattern is to generate embeddings in a batch or streaming pipeline, store vectors with metadata, retrieve a broader candidate set, filter by tenant, permissions, language, or freshness, and rerank with another model or business rules. A common misunderstanding is that the nearest vector is automatically the best answer. It depends on the model, metric, data chunking, filters, and ranking.

Go deeper

Everything DataEmbeddings and Vector SearchExplain embedding vectors, similarity metrics, nearest neighbor search, recall, precision, and ranking in retrieval systems.Open the lesson

Common questions

What is the difference between an embedding and a vector database?: An embedding is the numerical representation produced by a model. A vector database is infrastructure for storing those vectors, associating them with records and metadata, indexing them, and searching for nearby vectors efficiently. The model defines the geometry of meaning; the database makes that geometry usable at application scale.
Which similarity metric should I use?: It depends on the embedding model and how its vectors were trained. Cosine similarity is common when direction matters more than magnitude, dot product is common for some retrieval-trained models, and Euclidean distance measures straight-line distance. Do not choose by habit alone; use the metric recommended for the model and validate it on real queries.
Are embeddings a replacement for keyword search?: Not always. Embeddings are strong when meaning differs from wording, but keyword search is often better for exact identifiers, error codes, names, and rare terms. Many production systems use hybrid retrieval: lexical search for exact signals, vector search for semantic matches, then filtering and reranking to produce the final order.
Why do vector search results sometimes look wrong?: The system is returning items that are close under the model’s learned geometry, not items a human has explicitly judged relevant. Bad chunking, mismatched embedding models, the wrong distance metric, weak metadata filters, or an approximate index with low recall can all hurt results. Evaluation needs realistic queries and relevance judgements, not just inspection of a few examples.

Every term