Vector Databases

The Problem: Meaning Isn’t Keywords

 keyword search misses SEMANTIC matches:

 query:   "affordable running shoes"
 match:   "budget-friendly athletic sneakers"   ← zero shared words!

 solution: represent MEANING as vectors.
 embedding models map text/images into high-dim space where
 SIMILAR MEANING = NEARBY POINTS:

 "running shoes"    → [0.21, -0.44, 0.87, ...]  (768-1536 dims)
 "athletic sneakers"→ [0.19, -0.41, 0.85, ...]  ← close!
 "tax filing"       → [-0.88, 0.12, -0.02, ...] ← far away

Similarity Search Mechanics

 find k nearest neighbors by distance:

 cosine similarity:  angle between vectors (most common)
 euclidean distance: straight-line distance
 
 brute force: compare against EVERY vector
   10M docs × 1536 dims × per-query = too slow for online serving

 ANN (Approximate Nearest Neighbor) indexes fix it:

 HNSW:  hierarchical proximity graph; log-ish search,
        great recall/speed balance — industry default
 IVF:   cluster space, search nearby clusters only
 PQ:    compress vectors for memory scale

 "approximate" tradeoff: ~95-99% recall at 100-1000x speedup —
 tunable per application via index parameters.

Where Vector Search Powers Products

Application	Query pattern
Semantic search	Natural-language → nearest documents
RAG for LLMs	Question → relevant context chunks
Recommendations	Item you liked → similar items
Dedup/clustering	Near-duplicate detection
Image/audio search	Embed non-text, search cross-modal

 RAG (retrieval-augmented generation) is THE driver today:

 user question ──embed──► [vector DB top-k chunks]
                              │
                              ▼
              [LLM answers grounded in retrieved context]

Chunking and Pipeline Design

 the pipeline matters more than the database choice:

 documents → CHUNK (200-800 tokens, overlap) 
           → EMBED each chunk
           → store {vector, text, metadata}
           
 metadata filtering is essential hybrid power:
   vector search WHERE category="shoes" AND price<100
   
 production systems increasingly run HYBRID:
   BM25 keyword + vector similarity, fused scores —
   keywords catch exact SKUs/names, vectors catch meaning.

The Storage Landscape

 dedicated:   Pinecone, Weaviate, Milvus, Qdrant
 extension:   pgvector (Postgres), Redis vector sets

 honest guidance:
 < 1M vectors or already-on-PG     → pgvector; done.
 massive scale / complex filters /
 multi-tenant isolation needs      → dedicated engine
 
 pgvector's rise proves a point: most products overestimate
 their vector scale needs by orders of magnitude.

Operational Realities

 - embeddings are MODEL-BOUND: switching models = re-embedding
   everything (version your embedding model per record!)
 - index builds are expensive: batch inserts, background builds
 - dimension × count drives memory: 10M × 1536 f32 ≈ 60GB raw;
   quantization (int8/product-quantization) cuts 4-32x with
   modest recall cost
 - freshness: same CDC-sync pattern as search engines —
   it's another derived read store

Interview Framing

“Add semantic search to docs product” scored shape: chunking strategy stated, embedding model named as a pinned dependency, pgvector-vs-dedicated decision WITH threshold reasoning, hybrid BM25+vector mention, re-embedding-on-model-change flagged. RAG framing shows current-era fluency; the pgvector-default instinct shows engineering restraint.