3:7
A vector database is a database designed to store, index, and search high-dimensional numeric vectors called embeddings, rather than traditional rows of structured data. Vector databases are a core piece of infrastructure behind semantic search, recommendation systems, and retrieval-augmented generation (RAG), where finding items by conceptual similarity matters more than finding exact matches on a specific field.
Traditional relational databases are optimized for exact matches and range queries on structured columns - finding rows where a price is between two values, or a name equals a specific string. They aren't designed to answer questions like "which of these million documents is most similar in meaning to this new one," which requires comparing high-dimensional vectors (often hundreds or thousands of numbers per vector) against every other vector and ranking by similarity. Doing this efficiently at scale requires specialized indexing structures that regular B-tree or hash indexes don't provide, which is what vector databases are built around.
An embedding model converts a piece of content - text, an image, audio - into a fixed-length list of numbers (a vector) that captures its meaning in a way that can be compared mathematically. Content with similar meaning produces vectors that are close together in this vector space, even if the original content shares no exact words. A vector database's core job is storing millions or billions of these vectors alongside a reference to their original content, and making it fast to find the vectors closest to any given query vector.
"Closeness" between vectors is measured using a similarity metric. The most common is cosine similarity, which measures the angle between two vectors regardless of their magnitude - useful because it focuses purely on directional similarity in meaning. Euclidean distance measures straight-line distance between vectors, and dot product combines both direction and magnitude. Which metric to use generally depends on how the embedding model that produced the vectors was trained, since most embedding models are optimized for one particular metric.
Computing exact similarity against every stored vector (a brute-force scan) becomes too slow once a collection grows into the millions. Vector databases instead use approximate nearest neighbor (ANN) algorithms - such as HNSW (Hierarchical Navigable Small World graphs) or IVF (Inverted File Index) - which build an index structure that can find vectors that are very likely, but not mathematically guaranteed, to be the closest matches, in a small fraction of the time a full scan would take. This tradeoff between perfect accuracy and speed is usually well worth it in practice, since the top few results rarely change meaningfully between exact and approximate search.
results = vector_db.query(
vector=embed("how do I reset my password?"),
top_k=5,
filter={"category": "support-docs"}
)Real-world vector search is rarely pure similarity search in isolation - queries are usually combined with metadata filters, such as restricting search to documents from a specific user, date range, or category. Most vector databases support storing structured metadata alongside each vector and let a query combine an ANN similarity search with traditional filter conditions, narrowing the candidate set before or during the similarity search.
The vector database landscape includes dedicated, purpose-built systems designed specifically for vector search, as well as vector search extensions added to existing general-purpose databases so that vectors can live alongside an application's regular relational data. The right choice generally depends on scale, whether vector search needs to be tightly integrated with existing structured data, and operational preferences around running a new dedicated system versus extending infrastructure that's already in place.
By: Tomas Silny
Edited: 2026-08-13 06:50:00