Vector database
A vector database stores data as embeddings — lists of numbers that capture meaning — and finds the items most similar to a query by mathematical distance rather than exact keyword match. It is the retrieval engine behind most RAG systems and semantic search.
Traditional databases match exact values; a vector database matches meaning. You convert text, images, or other content into embeddings, store them, and at query time convert the question into an embedding too, then return the nearest neighbours. That is how a search for 'how do I get a refund' surfaces a passage titled 'returns policy' even with no shared words. It is the storage-and-search layer that makes RAG and semantic search practical at scale.
When building a product, the vector database is one part of a pipeline, not the whole thing — its quality depends on the embedding model you chose, your chunking, and often a reranking step on top. Picking a dedicated vector store versus a vector extension on a database you already run is a real trade-off: operational simplicity often beats raw benchmark speed. We choose based on the data volume and the rest of the stack, not on hype.
// faq
Frequently asked questions
- Do I always need a dedicated vector database for RAG?
- No. For small to medium datasets, a vector extension on a database you already operate (or even an in-memory index) is often simpler and plenty fast. A dedicated vector store earns its place at large scale or with heavy filtering and high query volume. Choose for operational simplicity first; the embedding model and chunking affect answer quality far more than the store you pick.