Vector Similarity Search

Store high-dimensional embedding vectors alongside records and serve approximate nearest-neighbor (ANN) queries using specialized indexes (HNSW, IVF, FAISS), enabling semantic similarity search: finding records whose meaning is close to a query, not just records whose text matches exactly.

Keyword search cannot surface semantically related content: a query for "car" does not match documents containing "automobile" unless explicitly synonymized. Vector similarity search finds semantically similar content regardless of exact keyword match, enabling RAG (Retrieval Augmented Generation), recommendation systems, semantic duplicate detection, and image similarity.

Modern machine learning models (BERT, OpenAI embeddings, Cohere, etc.) can encode text, images, and structured data as dense floating-point vectors in high-dimensional space (512–3072 dimensions). Two semantically similar items produce vectors close in cosine or Euclidean distance. This enables "find items similar to this query" by encoding the query as a vector and finding the nearest neighbors in the index.

Brute-force nearest neighbor search (compare query vector against every stored vector) is O(n × d) and becomes prohibitively slow at millions of vectors. Approximate Nearest Neighbor (ANN) indexes trade a small recall loss for orders-of-magnitude faster lookup:

HNSW (Hierarchical Navigable Small World): builds a multi-layer graph where upper layers provide long-range navigation shortcuts and lower layers provide precise neighborhood traversal. Lookup time is O(log n). Used by pgvector (PostgreSQL), Weaviate, Qdrant, Chroma, and Pinecone. Very fast queries, higher memory usage.

IVF (Inverted File Index): partitions vectors into K clusters; at query time, searches only the nearest M clusters. Sub-linear lookup at the cost of reduced recall if the nearest neighbor is in an unsampled cluster. Used in FAISS, Pinecone's internal index.

PQ (Product Quantization): compresses vectors by dividing each into sub-vectors and quantizing each sub-vector to a codebook entry. Reduces memory by 8–32× at the cost of slight recall degradation. Typically combined with IVF (IVF-PQ).

pgvector (PostgreSQL extension) supports HNSW and IVF-Flat indexes natively. It is suitable for datasets up to ~10M vectors. Dedicated vector databases (Pinecone, Weaviate, Qdrant, Chroma, Milvus) handle hundreds of millions to billions of vectors with horizontal sharding and specialized storage.

With pgvector, adding vector search means enabling the extension, adding a vector column, and building an HNSW index on it:

CREATE EXTENSION vector;

ALTER TABLE documents ADD COLUMN embedding vector(1536);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)

WITH (m=16, ef_construction=64);

SELECT id, content, embedding <=> $1::vector AS distance

FROM documents ORDER BY distance LIMIT 10;

The embedding pipeline has three points of contact: at write time, call an embedding API (OpenAI, Cohere) and store the resulting vector; at query time, embed the query and execute the ANN search; and on refresh, if the source document content changes, re-embed and update the stored vector. HNSW index builds are memory-intensive in pgvector; beyond roughly 10M vectors, a dedicated vector database (Pinecone, Weaviate, Qdrant, or Chroma, as managed or self-hosted options respectively) is usually the better fit.