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.
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.
FAQ
What is a vector database in simple terms?
A vector database stores data as vectors — long lists of numbers called embeddings that capture meaning. Instead of matching exact words, it finds items whose vectors are closest to your query's vector. So a search for 'how to reset my password' can return a help article titled 'recover a forgotten login', because they mean the same thing. It is the engine behind semantic search, recommendations, and the retrieval step in most AI assistants.
How is a vector database different from a normal database?
A normal (relational) database is built for exact, structured queries: find the row where id = 42, or where country = 'France'. A vector database is built for similarity: find the items most like this one. It does not look for an exact match — it ranks results by how close their vectors are. The two are complementary. Many apps use a normal database for records and a vector database for meaning-based search.
How does similarity search actually work?
Three steps. First, an embedding model turns each item (a document, image, or sentence) into a vector. Second, the vector database stores those vectors in a special index (such as HNSW or IVF) that makes nearest-neighbour search fast, even over millions of items. Third, when a query comes in, it is embedded too, and the database returns the vectors closest to it by distance. You get the most similar items back in milliseconds.
Which vector databases are popular in 2026?
Common options include Pinecone, Weaviate, Qdrant, Milvus, and Chroma, plus pgvector, which adds vector search to PostgreSQL so you can keep everything in one database. The right choice depends on scale, whether you want a managed service or to self-host, and whether you need vectors alongside your existing relational data. For small projects, pgvector or Chroma are easy starting points.
Originally published on alexi.sh.
Top comments (0)