Vector Database
A database built to store embeddings and find the most similar ones fast — the search engine behind meaning-based retrieval.
When not to use it
- For small collections. Under roughly ten thousand vectors, a NumPy array and brute-force cosine similarity is faster to build, exact, and free of a new service to run.
- When you need exact matching, filters, or joins as the primary access pattern. That's what your existing database already does well.
- As a first move. Most teams reach for a vector DB before proving retrieval helps at all. Prove the retrieval, then buy the infrastructure.
Reach for something else instead
- pgvector or similar extensions — vectors inside the database you already operate, which is usually the right answer.
- In-memory search (FAISS, or plain NumPy) for modest corpora, embedded in your app.
- Keyword or hybrid search when semantic similarity was never the bottleneck.
Read more on the blog
- Do you actually need a vector database?Vector databases became the default first purchase for anyone building with AI. For most projects they're the wrong first move, here's how to tell whether yours is the exception.
- Beyond vector search: how RAG actually works in 2026RAG stopped being "vector database plus a language model" a while ago. Here's how retrieval-augmented generation actually works now, chunking, embeddings, reranking, knowledge graphs, and agentic retrieval, and where each piece quietly breaks.
- Your RAG system isn't hallucinating. It never found the answer.When a RAG system gives a bad answer, almost everyone blames the model. Usually the right passage was never retrieved, and that changes everything about how you fix it.
- What are embeddings? How AI turns meaning into numbersWhen a search returns the right result without sharing a single keyword, when a chatbot pulls the relevant document, when a store recommends something that just fits, the technology underneath is almost always embeddings. They rest on one powerful idea: turn meaning into geometry, so that similar things sit close together in space and similarity becomes something a computer can measure.
Further reading
- Johnson, Douze & Jegou (2017), Billion-scale similarity search with GPUs — FAISS, and the ANN trade-offs underneath every vector store.
- Malkov & Yashunin (2016), Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs — the index most of them actually run.
- Weber, Schek & Blott (1998), A Quantitative Analysis and Performance Study for Similarity-Search Methods in High-Dimensional Spaces — the curse of dimensionality, established long before the hype.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Treating approximate nearest-neighbour results as exact. ANN trades recall for speed — by design, it sometimes misses the best match.
- Ignoring metadata filtering until late, then discovering that filtering plus ANN interact badly and results get worse.
- Re-embedding everything for every model change, and not planning for that day. It always comes.
At a glance
Where this sits
A destination. 8 concepts lead here, and nothing in the corpus depends on it.
Computed from the prerequisite graph, not assigned. How this works