Vectors: how to better support a nasty data type in PostgreSQL
summary
Explains concrete engineering: pgvector extensions (versions 0.5, 0.6, 0.7) add IVF‑flat and HNSW indexing, SIMD/CPU dispatch and parallel index builds that cut build time 30–150x; shows HNSW defaults like m=16, e_construction≈256, quantization options (scalar ≈8–9x size, binary up to ~16x), and real numbers—1,536‑dim vectors ≈6 KB each, billions handled, P99 latency and throughput scaling. Identifies remaining work: filtering/WHERE interactions, TOAST and 8 KB page limits, double storage for table+index, vacuum/update costs, and distributed/parallel query gaps.
AI-written summary · about
chapters (15)
- 0:00Introduction and agenda
- 1:09Why vectors matter in AI
- 10:59Postgres as a vector database
- 17:57Indexing vectors in PG Vector
- 24:36Quantization techniques
- 31:17Index build time impact
- 34:31The 8KB page size problem
- 39:06Filtering and hybrid search
- 42:21Vacuum and updates in PG Vector
- 43:02Distributed queries and parallelism
- 44:46Hardware acceleration
- 45:50Future challenges: tensors
- 47:13Priorities for PG Vector
- 48:36Summary and call to action
- 48:56Q&A
related talks
48mVectors are the new JSON
25mVector data in Postgres - how's it different from "normal" data?
52mVector search is now boring, but PostgreSQL has ways to go
52mpgvector Newbie to Expert
51mVector data in Postgres: Size, TOAST, Filters and Performance
41mPostgreSQL for AI. Real Vector Search in PostgreSQL
44mScaling Semantic Search in PostgreSQL
48mFrom Text to Meaning: pgvector Transforms PostgreSQL Search