Traditional databases answer queries like 'Find all users where age > 30.' Vector databases answer queries like 'Find the 10 most semantically similar documents to this sentence.' These are fundamentally different problems requiring fundamentally different data structures.
**The problem they solve:**
When you embed text (or images, or audio) into high-dimensional vectors, you need to find the nearest neighbors to a query vector — fast, at scale. Brute force search over millions of vectors is too slow. You need specialized index structures.
**How vector search works:**
- **HNSW** (Hierarchical Navigable Small World): Builds a graph where each node connects to nearby nodes across multiple layers. Query traverses layers, honing in on nearest neighbors. Sub-millisecond search over billions of vectors.
- **IVF** (Inverted File Index): Clusters vectors, searches only the most relevant clusters. Faster but less accurate.
- **Product Quantization**: Compresses vectors to reduce memory usage, with some accuracy tradeoff.
**Major vector databases:**
- **Pinecone**: Managed cloud service, easiest to get started
- **Weaviate**: Open source, hybrid search (semantic + keyword)
- **Qdrant**: Open source, Rust-based, very fast
- **Chroma**: Open source, local-first, popular in dev environments
- **pgvector**: PostgreSQL extension — use your existing DB for vector search
**The hybrid search trend**: Pure semantic search misses exact matches. Hybrid search combines vector similarity with keyword matching (BM25) for better results — now standard in production RAG systems.
**Key takeaway:** Vector databases enable fast similarity search over embeddings — the core infrastructure for RAG, semantic search, and recommendations.