What is a vector database?
A vector database is a database built to answer one question very fast: "Which stored items are most similar to this one?" Instead of matching exact words or values, it compares meaning, represented as lists of numbers called vectors. That single ability powers semantic search, retrieval-augmented generation (RAG), recommendations, duplicate detection and much more.
The problem with normal search
Imagine a support knowledge base. A customer types:
"My card got declined at the shop"
The article that answers them is titled "Why was my payment refused?". A traditional keyword search looks for the words card, declined and shop — and finds nothing useful, because the article uses payment and refused. The meaning is the same; the words are different.
A regular database is excellent at exact questions: "Find the order with ID 4821" or "Find customers in Pune who signed up after March." It has no idea that declined and refused mean nearly the same thing.
The idea in one picture
Imagine a huge library where books are not arranged alphabetically but by what they are about. Cookbooks sit together; books on Italian cooking sit closer to each other than to books on baking; a book on pasta sits right next to one on pizza. To find books like the one in your hand, you walk to its spot and look at its neighbours.
A vector database builds exactly that library, but in a mathematical space:
- Every item (a sentence, a document chunk, an image, a product) is turned into a vector — a list of numbers that captures its meaning — by an embedding model.
- Similar items get vectors that sit close together in that space.
- To search, your query is turned into a vector too, and the database returns the nearest neighbours.
A vector database stores vectors and finds the closest ones to a query vector — fast, even among millions or billions of items. Everything else in this handbook is detail on how it does that well.
What makes it a database
Finding similar vectors is the core, but a vector database also does the things you expect from any database:
- Stores each vector together with an ID and metadata (title, date, author, tenant…).
- Updates and deletes items as your data changes.
- Filters results by metadata — "similar articles, but only in English and published this year."
- Scales with replication, sharding and persistence.
- Secures data with authentication and access control.
Where you'll meet vector databases
| Use case | What gets compared |
|---|---|
| Semantic search | A user's question vs. documents |
| RAG for chatbots | A question vs. chunks of company knowledge, to give an LLM the right context |
| Recommendations | A product or user vs. other products |
| Duplicate detection | A new support ticket vs. existing tickets |
| Image search | A photo (or text describing it) vs. a photo library |
| Anomaly detection | A transaction vs. normal transaction patterns |
Do you actually need one?
Not always. A dedicated vector database earns its place when you have a lot of vectors, need low latency, or need features like filtering and hybrid search at scale. For smaller projects, a vector extension to a database you already run — such as pgvector for PostgreSQL — is often the simplest choice. We cover this decision in Choosing a vector database.
A rough guide: up to a few hundred thousand vectors, almost anything works, including plain brute-force search. In the millions and beyond, the indexing techniques in this handbook start to matter a lot.
How this handbook is organised
- The basics — vectors, embeddings, similarity and nearest-neighbour search.
- How it works inside — the indexes (HNSW, IVF, quantization) that make search fast.
- Using a vector database — data modelling, updates, filtering, hybrid search and multi-tenancy.
- Hands-on — pgvector in practice, and building a tiny vector database yourself.
- Choosing & running — the landscape, sizing, tuning, evaluation and operations.
You don't need any maths beyond school arithmetic. Every concept is introduced with a small example first.
Senior Full-Stack Engineer · AI & AWS. I build production search, RAG and AI systems on AWS and Postgres.