A vector database stores embedding vectors and is purpose-built to answer one specific question extremely efficiently at scale: "which stored vectors are most similar to this query vector?" — the operation everything in RAG and semantic search is built on.
Why Not Just Use a Regular Database?
Brute-force approach (works, doesn't scale):
For 10 million stored vectors, compare the query vector against
ALL 10 million, one by one, computing cosine similarity each time.
→ Technically correct, but far too slow for real-time search
once you're past a modest number of vectors.Vector databases solve this with specialized indexing structures (see Vector Index) that make similarity search dramatically faster than brute force, trading a small amount of accuracy for large gains in speed — see Approximate Nearest Neighbor.
Core Operations
| Operation | What It Does |
|---|---|
| Upsert | Store a vector, along with an ID and optional metadata |
| Query / search | Given a query vector, return the top-k most similar stored vectors |
| Metadata filtering | Restrict search to vectors matching certain metadata conditions — see Metadata Filtering |
| Delete/update | Remove or replace vectors as underlying content changes |
A Conceptual Landscape of Options
Several tools exist in this space, with different design points — this is a conceptual overview, not a performance benchmark or a "best tool" ranking, since capabilities and performance characteristics evolve and depend heavily on your specific workload:
| Tool | General Positioning |
|---|---|
| FAISS | A library (not a hosted service) for efficient similarity search, commonly used for local/embedded or self-managed setups |
| Chroma | An open-source vector database often used for prototyping and small-to-medium applications |
| Pinecone | A managed, hosted vector database service |
| Weaviate | An open-source vector database with hybrid search and additional built-in features |
| Qdrant | An open-source vector database, available self-hosted or as a managed service |
| PostgreSQL (with a vector extension) | Adds vector similarity search to an existing relational database, useful when you already run Postgres |
| MongoDB (vector search) | Adds vector similarity search capability to an existing document database |
Always check each project/provider's current documentation for capabilities, since this space evolves quickly — this table is a starting orientation, not a permanent feature comparison.
Common Mistakes
- Choosing a vector database based on marketing claims or hearsay about "which is fastest" without testing against your own actual data and query patterns
- Adopting a dedicated vector database for a small-scale project where a simple brute-force or existing-database extension approach would have been sufficient
Interview Relevance
Q: "Why can't you just use a regular SQL database for vector similarity search?" — the expected answer covers the lack of efficient similarity-search indexing in traditional relational engines, though modern extensions (like Postgres vector extensions) are narrowing this gap — see Vector Database vs SQL.
Practice Question
A team has 5,000 documents and wants basic semantic search. Another team has 50 million documents needing sub-second search. Discuss how their infrastructure choices might reasonably differ.
