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. PostgreSQL with pgvector extension now supports vector search, making it viable for many use cases where you want to avoid separate infrastructure.
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
- DuckDB: In-process with vector support, useful for analytics workflows
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 or 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. For analytics or in-process use cases: DuckDB.