Technology · Vector database
Vector Databases
Specialized storage and approximate nearest neighbor (ANN) retrieval engines for dense embeddings. HNSW graphs, inverted file indexes (IVFFlat), recall versus latency trade-offs, pre-filtering challenges, pgvector vs dedicated stores, semantic search, and RAG architectures.
11 min read
Vector databases are purpose-built systems designed to index, store, and query high-dimensional numerical vectors (embeddings). Unlike traditional databases that query by exact keyword matches or structured SQL predicates, a vector database performs Approximate Nearest Neighbor (ANN) search to discover semantically similar items across millions or billions of items in milliseconds.
Popular options include dedicated engines like Qdrant, Pinecone, Milvus, and Weaviate, as well as extensions for relational systems like pgvector for PostgreSQL and vector plugins for Elasticsearch.
When to reach for one
- Retrieval-Augmented Generation (RAG): Searching a knowledge base for chunks of text semantically relevant to a user's prompt before passing them to a Large Language Model (LLM).
- Semantic and multi-lingual search: Finding documents, FAQs, or code snippets that share conceptual meaning with a query even when they do not share any exact words.
- Multimodal similarity matching: Matching text queries to images, audio tracks, or video frames using shared embedding spaces (like CLIP).
- Recommendation systems: Recommending articles, products, or videos by finding items geometrically close to a user's preference vector.
- Deduplication and anomaly detection: Spotting near-duplicate documents or detecting fraud vectors that deviate from known legitimate behavioral clusters.
If your query patterns rely on exact equality, numerical ranges, or structured transactions, use PostgreSQL. If you need lexical token matching with BM25 scoring and typo tolerance, use Elasticsearch.
Embeddings and distance metrics
An embedding model (such as OpenAI text-embedding-3-small or open-source BGE models) translates unstructured data into a dense array of 32-bit floating-point numbers:
doc_vector = [0.024, -0.081, 0.142, ..., 0.009] (typically 768 to 1536 dimensions)Similarity between two vectors $u$ and $v$ is computed geometrically:
- Cosine Similarity: Measures the angle between two vectors, ignoring their magnitudes. Standard for natural language and text embeddings.
- Dot Product (Inner Product): Equivalent to cosine similarity if all vectors are pre-normalized to unit length ($L_2 = 1.0$). Computationally faster because it avoids square root divisions.
- Euclidean Distance ($L_2$): Measures the straight-line geometric distance. Common for audio or image feature embeddings.
Exact kNN vs Approximate Nearest Neighbor (ANN)
Finding the true closest vector requires an exhaustive flat scan (exact kNN). Computing the distance between a query vector and 10 million 1536-dimensional vectors requires:
10,000,000 vectors * 1,536 dimensions * 4 bytes ≈ 61.4 GB memory bandwidth per queryAt 50 GB/s memory bandwidth, a single query takes over one second. To achieve sub-10 millisecond response times at high query volume, vector databases sacrifice 1% to 5% accuracy by using Approximate Nearest Neighbor (ANN) index structures:
Exact Flat Scan (kNN)
- 100% recall (perfect accuracy)
- No index build overhead
- Instant zero-cost updates
- Linear O(N) latency scales directly with dataset size
- Unusable for real-time queries past 100k vectors
Pick it when: Small datasets (< 50,000 vectors) or offline evaluation benchmarks.
Approximate Search (ANN)
- Sub-linear O(log N) latency
- Evaluates thousands of queries per second
- Under 10 ms P99 search
- Recalls 95% to 99% of true neighbors (slight accuracy drop)
- High RAM footprint to maintain navigation graphs
- Slower index build and insertion times
Pick it when: Production semantic search, RAG pipelines, large-scale recommendations.
Core ANN algorithms: HNSW vs IVF
The two dominant indexing families are:
- HNSW (Hierarchical Navigable Small World): A multi-layered graph where vertices are vectors and edges represent proximity. Greedy routing hops across coarse long-distance links on upper layers, then descends to lower layers for precise local convergence. HNSW delivers the best latency-versus-recall trade-off but consumes significant RAM (each vector requires dozens of pointer edges).
- IVFFlat (Inverted File Index): Partitions the vector space into $K$ Voronoi clusters using k-means. Queries compare against cluster centroids, then scan only the inverted lists of vectors in the closest n_probe clusters. Uses less memory than HNSW, but recall drops sharply if query vectors fall near cluster boundaries.
- Quantization (PQ / SCaNN): Compresses 32-bit floats into 8-bit codes (Product Quantization) to fit billions of vectors into RAM, trading precision for an 80% to 90% memory reduction.
The filtering dilemma
Real-world searches never search vectors in a vacuum: queries almost always specify metadata filters (for example, "find documents similar to X where tenant_id = 'acme' and created_year >= 2024").
Handling both vector similarity and structured predicates is surprisingly difficult:
Post-Filtering
- Runs standard fast vector ANN search first
- If the filter is selective (e.g. 1% match), ANN returns 100 results, of which only 1 passes the filter, leaving the user with empty results
Pick it when: Filters that match a large majority (> 80%) of the collection.
Pre-Filtering
- Filters metadata first to get matching document IDs
- ANN graph traversal breaks if non-matching nodes are skipped; graph becomes disconnected or degrades to a slow exhaustive scan
Pick it when: Very small matching subsets (< 1,000 records).
Single-Stage / Iterated Filtering
- Modern vector engines (Qdrant, Milvus, pgvector) dynamically switch between graph traversal and payload filtering during the search traversal
- Guarantees top-K results regardless of filter selectivity
- More complex engine internals
Pick it when: Multi-tenant SaaS, access-controlled document retrieval.
pgvector vs Dedicated Vector Databases
PostgreSQL + pgvector
- Single datastore for both relational data and embeddings
- ACID transactions, foreign keys, row-level security (RLS)
- Zero data synchronization pipelines needed
- Supports both HNSW and IVFFlat
- Memory management shared with relational buffers
- Slower index build times on tens of millions of rows
- No horizontal sharding out of the box
Pick it when: Datasets under 10 million vectors, teams already running PostgreSQL.
Dedicated Vector DB (Qdrant, Pinecone, Milvus)
- Distributed clustering and replication built for vector scale
- Hardware-accelerated SIMD / AVX-512 distance math
- Specialized payload indexing and memory-mapped disk storage
- Handles billions of vectors horizontally
- Another database to operate and monitor
- Dual-write consistency issues between primary DB and vector DB
- Network latency overhead between application and vector store
Pick it when: Over 20 million vectors, dedicated high-throughput search, independent scaling.
Numbers to quote
- Vector dimensions
- 384 (MiniLM), 768 (BERT), 1536 (OpenAI), 3072 (Large)
- Raw memory footprint (1536-dim)
- 6 KB per vector raw float32; ~8 to 12 KB with HNSW graph overhead
- HNSW search latency
- 2 to 10 ms P99 on 10 million vectors in RAM
- Recall target
- 95% to 99% 10-recall@10 for production semantic search
- Memory for 1M vectors (1536-dim)
- ~8 to 10 GB RAM required to keep HNSW index hot
Where it bites
- Memory exhaustion: HNSW graphs must reside in RAM for microsecond traversal. Ten million 1536-dimensional vectors with graph edges consume over 100 GB of RAM. Without Product Quantization or memory-mapped storage, server costs quickly spiral.
- Embedding model drift: If you change or fine-tune your embedding model, every existing vector in the database must be re-embedded and re-indexed. You cannot compare vectors generated by different models.
- Hybrid search complexity: Vector search excels at conceptual meaning but struggles with exact entity codes, stock tickers, and phone numbers. Production search systems combine dense vector search with sparse keyword search (BM25) using Reciprocal Rank Fusion (RRF).
Try it
Document Search Service HLD
Design a semantic search and RAG pipeline indexing tens of millions of documents with hybrid keyword and vector retrieval.