Vector Database
A vector database stores embeddings and retrieves nearby vectors efficiently.
Use a vector database when semantic retrieval needs to scale beyond simple in-memory search.
Use when
- RAG over many documents
- Similarity search at scale
- Metadata-filtered retrieval
- Product features built around semantic matching
Avoid when
- Tiny prototypes
- Exact keyword search alone
- Relational transactions
- Systems without retrieval quality evaluation
What it gives you
A vector database stores vectors and returns the nearest items for a query vector. For RAG, that usually means finding document chunks that are semantically similar to the user’s question.
The useful production features are often filtering, metadata, updates, and observability, not just the vector index itself.
When to avoid it
If you have a small corpus, a local index or existing database extension may be enough. Do not add a separate vector database before the retrieval problem requires it.
Common mistakes
- Treating the database choice as the main RAG quality lever.
- Ignoring metadata filters for tenant, permission, date, or document type.
- Skipping hybrid retrieval for exact terms.
Next decision
Choose a vector store after you know corpus size, update frequency, filtering needs, and retrieval evaluation criteria.