Vector Databases Guide — Embeddings, Search, and RAG
Vector databases store and search high-dimensional vector embeddings, the numerical representations produced by machine learning models. Unlike traditional databases that search by exact matching or range queries on structured fields, vector databases find the most similar vectors using distance metrics. They are essential infrastructure for modern AI applications including semantic search where meaning matters more than keywords, recommendation systems that find similar products or content, and retrieval-augmented generation that grounds large language model responses in factual, domain-specific knowledge.
The rise of vector databases parallels the explosion of embedding models. OpenAI’s text-embedding-3-small produces 1536-dimensional vectors, Google’s text-embedding-preview creates 768-dimensional vectors, and open-source models like BERT and Sentence Transformers generate embeddings that capture semantic meaning, context, and relationships. According to a 2024 report by Gartner, over 60 percent of organizations deploying generative AI applications have adopted vector databases as part of their retrieval infrastructure, making them one of the fastest-growing categories in data infrastructure.
Understanding Embeddings
Embeddings transform data — text, images, audio, or video — into numerical vectors in a high-dimensional space where semantic similarity corresponds to vector proximity. Words with similar meanings cluster together in specific regions of the vector space, related documents occupy nearby neighborhoods, and visually similar images have close embeddings regardless of differences in resolution, lighting, or cropping. This property enables search based on meaning and context rather than keyword matching, which fails for synonyms, paraphrases, and conceptually related content.
The quality of embeddings depends heavily on the model used to generate them. General-purpose models like OpenAI’s text-embedding-3-small work well for most text domains, while specialized models fine-tuned on specific domains like legal documents, medical literature, or code repositories provide better accuracy for those domains. The choice of embedding model should be validated on representative queries from the target domain to ensure adequate retrieval quality.
Distance Metrics
Vector databases support multiple distance metrics for comparing vectors, and the choice of metric should match the one used during embedding model training for optimal accuracy. Cosine distance measures the angle between vectors, ranging from 0 for identical direction to 1 for orthogonal vectors, and is suitable for normalized embeddings where vector magnitude carries no semantic meaning. Euclidean distance measures the straight-line distance in vector space and is sensitive to both direction and magnitude, making it appropriate when the magnitude of the embedding carries significance. Dot product measures similarity for magnitude-sensitive embeddings where larger magnitudes indicate stronger associations.
Approximate Nearest Neighbor Search
Exact nearest neighbor search compares the query vector against every stored vector, with time complexity O(n) where n is the number of vectors. For millions or billions of vectors typical in production systems, this linear scan is far too slow for interactive applications with sub-100-millisecond latency requirements. Approximate Nearest Neighbor search uses specialized index structures that reduce comparisons to O(log n) or better by trading perfect recall for dramatic speed improvements. ANN indexes achieve 90 to 99 percent recall while being 10 to 100 times faster than exhaustive search.
HNSW Index
Hierarchical Navigable Small World graphs are the most popular ANN index, offering state-of-the-art recall-speed trade-offs. HNSW builds a multi-layered graph structure where higher layers contain fewer nodes with long-range connections that enable rapid navigation across the entire vector space, and lower layers contain more nodes with short-range connections for fine-grained local search. Search begins by identifying the closest node at the highest layer, then descends through progressively lower layers to refine the result. HNSW provides excellent recall at query time but requires significant memory for the graph structure and longer index build times.
IVFFlat Index
Inverted File with Flat quantization divides the vector space into a fixed number of cells using k-means clustering during index construction. Search identifies the cells nearest to the query vector and searches only within those cells, dramatically reducing the number of distance comparisons required. IVF is faster to build than HNSW and uses less memory since it stores only the cluster assignments rather than a full graph. The trade-off is potentially lower recall for the same search time, though increasing the number of probes into nearby cells improves recall at the cost of slower queries.
Database Implementations
pgvector
pgvector adds vector similarity search to PostgreSQL as an extension, supporting both exact and approximate search using IVFFlat and HNSW indexes with all standard distance metrics. It integrates with PostgreSQL’s full ecosystem including ACID transactions, point-in-time recovery, streaming replication, and row-level security. For teams already using PostgreSQL, pgvector eliminates the operational overhead of maintaining a separate vector database while providing production-quality ANN search.
Pinecone
Pinecone is a fully managed vector database that handles all infrastructure concerns including sharding, replication, index optimization, and automatic scaling. It offers a simple API for index creation and querying with SDKs in Python, Node.js, Go, and Java, supports metadata filtering alongside vector similarity for hybrid search, and provides serverless and pod-based pricing options.
Qdrant
Qdrant is an open-source vector database written in Rust with a gRPC API for high-performance communication. It supports payload filtering that combines vector similarity with metadata filters in a single query without post-filtering, batch updates for efficient indexing, point versioning for concurrent consistency, and geo-filtering for location-aware vector search.
Retrieval-Augmented Generation
RAG is the most impactful application of vector databases in the age of large language models. When a user asks a question, the RAG system embeds the question using the same embedding model used during indexing, searches the vector database for the most relevant documents ranked by similarity, and includes those documents as context in the LLM prompt. This approach grounds LLM responses in factual, domain-specific information that was not in the model’s training data, significantly reducing hallucinations and enabling the model to answer questions about proprietary data or recent events.
The RAG pattern has been widely adopted through frameworks like LangChain, LlamaIndex, and Haystack, which provide abstractions for document chunking with configurable overlap, embedding model selection from multiple providers, vector database configuration for different performance profiles, and prompt template design for optimal response quality. Production RAG systems require monitoring for retrieval quality through relevance metrics, response quality through human evaluation, end-to-end latency for user experience, and cost tracking for embedding API usage.
Document chunking strategy significantly affects RAG quality. Splitting documents into chunks of 256 to 512 tokens with 10 to 20 percent overlap preserves context across chunk boundaries. Chunks that are too small lose context, while chunks that are too large dilute semantic focus and may exceed the LLM’s context window.
Hybrid Search
Many production systems combine vector similarity search with traditional keyword search for optimal relevance. Hybrid search merges results from both approaches, using techniques like reciprocal rank fusion to combine rankings. Keyword search excels at exact term matching and is less affected by embedding quality, while vector search captures semantic relationships that keyword search misses. Systems like Elasticsearch’s dense-text hybrid search and Pinecone’s sparse-dense fusion demonstrate that combining both approaches typically outperforms either method individually.
Vector Database Index Maintenance
Vector indexes require ongoing maintenance to sustain search quality over time. As new vectors are inserted, ANN index quality can gradually degrade because the index structure was optimized for the original data distribution. Periodic index rebuilding or incremental optimization restores search accuracy.
For HNSW indexes, the graph structure can become unbalanced with continued insertions. Some implementations support incremental optimization by periodically re-inserting existing vectors, which allows the graph to adapt to the current data distribution. For IVFFlat indexes, the cluster centroids computed during initial construction may no longer represent the data distribution after significant insertions, requiring reclustering.
Monitoring metrics include recall at various k values compared against ground truth, query latency percentiles at P50, P95, and P99, and index build time to detect performance regressions. Automated pipelines should trigger index rebuilds when recall drops below a configurable threshold or when a significant number of vectors have been added since the last rebuild.
Choosing the Right Vector Database
Selecting a vector database depends on scale requirements, operational capabilities, and existing infrastructure. pgvector is ideal for teams already using PostgreSQL, supporting up to millions of vectors. Pinecone offers the fastest path to production as a fully managed solution. Qdrant provides a balance of features and self-hosting capability. Milvus is designed for billion-scale vector search with distributed architecture and GPU acceleration.
Frequently Asked Questions
What is the difference between a vector database and a traditional database? Traditional databases search by exact matching or range queries. Vector databases search by similarity in high-dimensional space.
How do I choose between HNSW and IVFFlat indexes? Use HNSW when query speed and recall are critical and memory is available. Use IVFFlat when index build time or memory is constrained.
What is the best way to chunk documents for RAG? Split documents into chunks of 256 to 512 tokens with 10 to 20 percent overlap to preserve context across chunk boundaries.
Can I use a vector database without embeddings? No. Vector databases require embeddings as input. You must use an embedding model to convert your data into vector representations.
How does RAG reduce LLM hallucinations? RAG grounds LLM responses in retrieved factual documents, constraining the model to answer based on retrieved evidence rather than relying solely on its training data.
Database Sharding — PostgreSQL vs MySQL — SQL JOINs Explained