A Beginner’s Guide to
Vector Databases and Embeddings

Every modern search, recommendation, or retrieval system you interact with — semantic search, image similarity, RAG pipelines, recommendation engines — is quietly built on the same foundation: turning things into numbers and measuring distance between them. That foundation is embeddings, and the specialized databases built to search through them are vector databases.

What an embedding actually is

An embedding is a list of numbers — a vector — produced by a model, meant to capture the meaning of a piece of data. A sentence, an image, a product, or an audio clip can all be embedded into the same kind of fixed-length vector, typically anywhere from a few hundred to a few thousand dimensions. The key property that makes embeddings useful: things that are semantically similar end up with vectors that are close together in that high-dimensional space, while unrelated things end up far apart.

Text about similar topics clusters together once mapped into embedding space. (Image by author)

Measuring similarity

Once data is embedded, “similarity” becomes a geometry problem. The most common metric is cosine similarity, which measures the angle between two vectors rather than their raw distance — this makes it robust to differences in vector magnitude, which often reflects things like text length rather than meaning. Euclidean distance and dot product are also used depending on how the embedding model was trained; most embedding models are trained with a specific similarity metric in mind, and using the wrong one can quietly degrade results.

Why you can’t just use a regular database

Finding the nearest vectors to a query, exactly, means comparing it against every single vector in your dataset — an operation whose cost grows linearly with the size of the collection. That’s fine for a few thousand items but falls apart at the millions-to-billions scale most production systems operate at. Vector databases exist to solve this with approximate nearest neighbor (ANN) search: algorithms that sacrifice a small amount of accuracy for a dramatic speedup, typically returning results that are extremely close to — but not always exactly — the true nearest neighbors.

The most common indexing technique behind these systems is HNSW (Hierarchical Navigable Small World graphs), which organizes vectors into a layered graph structure that lets a search jump quickly toward the right neighborhood before refining locally. Other approaches include IVF (inverted file indexes) and product quantization, often combined to balance speed, memory, and accuracy for a given workload.

What these systems look like in practice

Popular vector databases — Pinecone, Weaviate, Qdrant, Milvus — all provide the same basic operations: insert a vector (usually alongside metadata like a document ID or source), query for the k nearest vectors to a given input, and filter results by that metadata. Many general-purpose databases, like Postgres via the pgvector extension, have also added vector search as a feature rather than requiring a dedicated system — a reasonable choice when your scale doesn’t yet demand a specialized store.

Common pitfalls

• Mismatched embedding models — vectors from two different embedding models are not comparable, even if they’re the same dimensionality.
• Stale embeddings — if the underlying content changes, the embedding must be regenerated, or search results silently drift.
• Over-trusting ANN — approximate search occasionally misses a true nearest neighbor; for some applications this matters, for most it doesn’t.
• Ignoring metadata filtering — pure vector similarity often needs to be combined with hard filters (date ranges, categories, permissions) to be useful in a real application.

Conclusion

Embeddings and vector databases have become foundational infrastructure for anything that needs to reason about similarity rather than exact matches — which, once you start looking, turns out to be most interesting problems in search, recommendations, and retrieval-augmented AI. Understanding the mechanics behind them makes it much easier to reason about why a search result showed up, or didn’t.