What Is a Vector Database?
Learn what a vector database stores, what it’s asked to do, and why ordinary databases needed help.
Once your documents are vectors, they need a home: somewhere to store millions of them, keep them up to date, and answer “which of these are closest to this question?” in milliseconds. That’s a vector database.
Each entry typically keeps four things together:
- An id, so the entry can be updated or deleted later.
- The vector, used to find it.
- The original text, because the vector is what you search with, but the text is what you hand to the model.
- Metadata: where it came from, when, which department, and who is allowed to see it.
Metadata turns out to be just as important as the vectors. Real questions come with conditions: only this year’s policies, only documents for the Dutch office, only what this employee is permitted to read. A vector database combines similarity with filters, so a junior employee’s question never retrieves the managers-only salary document, however similar it is.
The other key ingredient is an index: a clever structure that finds near vectors without comparing the question with every single one. Ordinary databases are great at exact lookups (“customer 1043”) but weren’t built for “closest in a 1,536-dimensional space”, which is why dedicated vector databases appeared, and why many ordinary databases have since added vector features. The next lesson opens up that index.
Key takeaways
- A vector database stores vectors together with an id, the original text and metadata.
- You search with the vector, but hand the model the text.
- Metadata filters (date, department, permissions) are combined with similarity search.
- An index makes finding near vectors fast; documents can be added, updated and deleted as they change.
Check your understanding
Go deeper (more technical)
Options range from libraries you embed in your own program, such as FAISS, to dedicated databases such as Chroma, Pinecone, Qdrant, Weaviate and Milvus, to extensions of ordinary databases such as pgvector for PostgreSQL. For a few thousand documents, almost anything works; differences matter at millions or billions of vectors and under heavy traffic.
Filtering is subtler than it looks: filtering after the similarity search can leave you with too few results, filtering first can make the index less efficient, so databases use various combined strategies.
Names are examples, not recommendations.