If you have read about RAG, AI search or recommendations, you have probably hit the term vector database. Here is the plain version. A vector database stores data as vectors - lists of numbers that capture meaning - and finds items by similarity, not by exact match. That one idea is what makes modern AI search feel like it understands you.
What a vector database actually is
Normal databases are great at exact questions: find the user with this ID, or every order from last week. They struggle with "find me things that mean the same thing." A vector database is built for exactly that.
It works on embeddings - the numeric fingerprints an AI model gives to text, images or audio. Items with similar meaning get vectors that sit close together. The database stores those vectors and, when you search, returns the ones nearest to your query.
How similarity search works
The flow has three steps:
- Embed. An embedding model turns each document, image or sentence into a vector.
- Index. The database stores those vectors in a special index (like HNSW or IVF) so it can search huge sets fast.
- Query. Your search is embedded too. The database returns the vectors closest to it by distance.
So a search for "how to reset my password" can surface an article called "recover a forgotten login." The words differ, but the meaning - and the vectors - are close.
Vector database vs a normal database
They solve different problems, and most real apps use both. A relational database holds your structured records and answers exact queries. A vector database answers "what is most like this?" You keep customer rows in one and searchable meaning in the other. Tools like pgvector even let you add vector search to a normal PostgreSQL database, so both live in one place.
Why it matters for AI
A vector database is the retrieval engine behind a lot of AI. It powers semantic search, product and content recommendations, and - most importantly - the retrieval step in RAG, where an assistant fetches relevant text before answering. Without fast similarity search over embeddings, none of those features would be practical at scale.
How the search stays fast: approximate nearest neighbour
Comparing your query vector against every stored vector - an exact nearest-neighbour search - is accurate but slow once you have millions of items. So vector databases lean on approximate nearest neighbour (ANN) algorithms. ANN trades a tiny bit of accuracy for an enormous speed gain: instead of checking every vector, it walks a smart index structure that gets it almost the closest matches, fast.
Two index families do most of the work:
- HNSW (Hierarchical Navigable Small World) builds a layered graph you can hop across quickly. It is the most common default - strong recall, low latency, more memory.
- IVF (Inverted File) clusters vectors into buckets and only searches the nearest buckets. It scales to very large sets and uses less memory, often paired with compression (PQ) to shrink vectors.
The knob you tune is recall vs latency: ask for higher recall (more of the true nearest neighbours) and the search does more work. Distance is measured with a metric - usually cosine similarity (angle between vectors), dot product, or Euclidean (L2) distance - and the embedding model you use generally dictates which one is correct.
Common vector databases - and when to use which
There is no single "best" option; the right pick depends on scale, whether you want a managed service or to self-host, and whether you need vectors next to existing relational data. The widely used choices in 2026:
| Database | Model | Good fit when… |
|---|---|---|
| pgvector | PostgreSQL extension | You already run Postgres and want vectors beside your normal data - one database, no extra service. |
| Chroma | Open-source, embeddable | Prototyping or a small app; quick to start locally. |
| Qdrant | Open-source, self-host or managed | You want rich metadata filtering and good performance with control over hosting. |
| Weaviate | Open-source, self-host or managed | You want built-in modules (hybrid search, vectorisation) and a schema-first approach. |
| Milvus | Open-source, built for scale | Very large collections (hundreds of millions+) and high-throughput workloads. |
| Pinecone | Fully managed (proprietary) | You want a hands-off, serverless service and would rather not run infrastructure. |
A simple rule of thumb: start with pgvector if you already use PostgreSQL, or Chroma for a quick prototype; reach for Qdrant, Weaviate, or Milvus when you need scale, filtering, or self-hosting control; choose Pinecone when you want a managed service and no ops. Most teams also run hybrid search - combining vector similarity with traditional keyword search - for the best of both.
The bottom line
A vector database stores meaning as vectors and finds items by similarity instead of exact match. It does not replace your normal database - it sits beside it and answers the questions a keyword search never could. If you are building anything with semantic search or RAG, a vector database is the piece doing the heavy lifting.
Related guides: What Is Prompt Engineering? Getting Better Answers from AI (2026).
