Scaling Semantic Search in PostgreSQL
summary
PGVector on PostgreSQL supports IVF‑flat and HNSW indexes; HNSW gives best runtime but needs huge memory — approximate formula shows 1M vectors ≈6 GB, 10M ≈65 GB, 100M ≈650 GB and build times from ~6 minutes to ~18 hours — so tuning instance size, shared_buffers and maintenance_work_mem is mandatory. Use HNSW memory formula, tune M and ef (grid‑search or heuristic paths, validate on 100k samples), apply partitioning or partial indexes for filtering, enable iterative index scan, and use half precision quantization to halve index size with negligible recall loss.
AI-written summary · about
chapters (13)
- 0:00Introduction and overview
- 1:52Vector databases basics
- 6:30Recall in approximate search
- 10:24Challenges in scaling PG Vector
- 22:26Problem space and trade-offs
- 23:08Instance sizing and parallel builds
- 24:11Dimensionality reduction
- 25:38Quantization techniques
- 30:33Filtering strategies
- 36:17Tuning HNSW parameters
- 40:51Hyperparameter tuning methods
- 41:31Mental model for vectors
- 42:13Q&A and closing
related talks
54mDissimilarity search...
52mVector search is now boring, but PostgreSQL has ways to go
41mPostgreSQL for AI. Real Vector Search in PostgreSQL
25mVector data in Postgres - how's it different from "normal" data?
48mFrom Text to Meaning: pgvector Transforms PostgreSQL Search
48mVectors are the new JSON
53mVectors: how to better support a nasty data type in PostgreSQL
52mpgvector Newbie to Expert