A database built for similarity
A vector database is a system designed to store embeddings — the numeric vectors that represent the meaning of text, images, or other data — and to answer one core question fast: which stored vectors are most similar to this query vector? Traditional databases excel at exact matches (“find the row where id = 42”), but they have no efficient way to ask “find the 10 items closest in meaning to this one.” Vector databases exist precisely to make that similarity query fast at scale, which is what makes semantic search, recommendations, and retrieval-augmented generation practical.
Why exact search does not scale
Comparing a query vector against every stored vector — a brute-force scan — is simple and exact, but it grows linearly with the dataset. At a few thousand vectors it is instant; at tens of millions it is far too slow for an interactive application. The cost is compounded because each comparison is over hundreds of dimensions. To stay fast, vector databases give up on guaranteeing the perfectly exact answer and instead use approximate nearest-neighbour (ANN) search, which returns almost all of the true nearest neighbours in a fraction of the time.
HNSW and IVF indexes
The speed comes from purpose-built indexes. The two most common are HNSW and IVF. HNSW (Hierarchical Navigable Small World) builds a layered graph of vectors; a search starts at a coarse top layer and hops greedily toward closer and closer neighbours, reaching the right region in a few steps. IVF (Inverted File) clusters vectors into buckets and, at query time, searches only the few buckets nearest the query rather than the whole dataset. Both deliver large speed-ups with a small, tunable loss of recall, and many systems combine them with vector compression to shrink memory use.
Vector database versus SQL and full-text search
It helps to see where a vector database sits among its neighbours. A SQL database handles exact, structured queries and transactions. Full-text search engines like Elasticsearch match keywords and handle typos and stemming, but they still fundamentally rely on shared words. A vector database matches by meaning, so a search for “automobile” can return a document about “cars” with no overlapping terms. These are complementary: a real application often filters on structured fields in SQL, retrieves by meaning in a vector index, and sometimes blends keyword and vector scores in a hybrid search.
When you actually need one
A dedicated vector database is not always the right call. For small collections — up to roughly a hundred thousand vectors — an in-memory library such as FAISS, or the pgvector extension that adds vector search to PostgreSQL, is often simpler and cheaper. Dedicated systems like Pinecone, Weaviate, Qdrant, and Milvus earn their place when you have millions of vectors, high query throughput, frequent inserts and deletes, or a need for rich metadata filtering alongside similarity. The honest rule of thumb: start with the simplest option that meets your scale, and graduate to a dedicated vector database only when measurements show you have outgrown it.