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.
Sources & 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.