What is a vector database?

In plain English

An ordinary database finds things by exact matches: a customer number, a date, a word. A vector database finds things by meaning. It stores embeddings, the long lists of numbers (“vectors”) that AI models use to capture what a piece of text or an image is about, and it is built to answer one question very fast: “which stored items are closest to this one?”

Why it matters

Vector databases are a core building block of RAG, the technique most “chat with your documents” tools and company chatbots use. A company’s documents are split into passages, each passage is turned into an embedding, and the embeddings go into a vector database. When someone asks a question, the question becomes an embedding too, and the database returns the closest passages for the AI to answer from, in milliseconds, even across millions of documents. AI agents use the same trick as a kind of long-term memory.

Popular options include dedicated services such as Pinecone, Weaviate, Milvus and Chroma, and add-ons that give existing databases vector search, such as pgvector for PostgreSQL.

An example

An online shop stores an embedding for every product description. A customer types “something warm for winter hiking that isn’t bulky”. No product contains those exact words, but the vector database returns thin insulated jackets and thermal base layers, because their meaning is closest.

What to watch out for

“Closest in meaning” is not the same as “correct” or “up to date”: if the stored documents are old or wrong, the AI’s answers will be too. Search quality also depends heavily on how documents are split into passages and which embedding model is used. And a vector database full of company documents needs the same access controls as the documents themselves, so people can’t use the AI to read files they shouldn’t see.

For the full picture of how this fits together, see RAG explained.