Vector search is now boring, but PostgreSQL has ways to go
summary
pgvector extension adds a vector type and custom indexes and yields up to ~150x faster index builds compared to earlier versions, making HNSW defaults work for many workloads. High‑dim embeddings (e.g. 1,500 dims ≈ 6 KB) collide with PostgreSQL’s 8 KB page size, forcing TOAST, hurting performance; vacuum and index rebuilds are costly. PG vector adds iterative scans, cost estimation and partial/compound indexes; Postgres 17/18 async/direct IO and parallel index builds cut hours to minutes, but page sizing, I/O patterns and hot‑path TOAST remain limits.
AI-written summary · about
chapters (9)
- 0:00Introduction and context
- 2:04How vector search works
- 6:21Challenges of vector search
- 12:05Growth of the pgvector extension
- 13:51Why vector search is boring
- 17:05Deep dive into HNSW
- 24:06Strategies for filtering
- 35:26Storage and memory management
- 46:57Hardware acceleration and future
related talks
53mVectors: how to better support a nasty data type in PostgreSQL
41mPostgreSQL for AI. Real Vector Search in PostgreSQL
25mVector data in Postgres - how's it different from "normal" data?
52mpgvector Newbie to Expert
48mVectors are the new JSON
48mFrom Text to Meaning: pgvector Transforms PostgreSQL Search
51mVector data in Postgres: Size, TOAST, Filters and Performance
44mScaling Semantic Search in PostgreSQL