Vector Database
A database optimized for storing and querying high-dimensional embedding vectors, enabling fast approximate nearest-neighbor search.
A vector database stores embedding vectors and supports efficient nearest-neighbor queries: given a query vector, return the k most similar vectors in the database. This is the retrieval engine in RAG pipelines.
Why not just use PostgreSQL?
Standard databases use exact-match queries ("WHERE id = 42"). Nearest-neighbor search over millions of 1536-dimension vectors requires specialized indexing algorithms like HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index) that approximate the nearest neighbors quickly. Without these indexes, a brute-force search over 1M vectors takes seconds; HNSW brings this to milliseconds.
Popular vector databases
- Pinecone: Fully managed, serverless pricing, strong production track record
- Weaviate: Open-source, self-hostable, supports multi-modal objects
- Qdrant: Open-source Rust-based, fast, good filtering support
- Chroma: Lightweight, local-first, great for prototyping
- pgvector: PostgreSQL extension - useful if you want to avoid a separate service
- Milvus: Highly scalable, used at billion-vector scale
Hybrid search
Pure vector search misses exact keyword matches (product IDs, names). Hybrid search combines dense vector retrieval with sparse BM25 retrieval, then uses a reranker to merge results. Most production RAG systems use hybrid search for this reason.
Choosing a vector database
For prototyping: Chroma. For local/self-hosted: Qdrant or Weaviate. For managed serverless with no ops overhead: Pinecone. For teams already on PostgreSQL: pgvector, which avoids adding another infrastructure component.