pgvector Is Fine. Your Autovacuum Isn't.
pgvector is a remarkable extension. The problem is rarely pgvector itself. It is what happens to the Postgres around it once embedding workloads start running at production scale. Vacuum behaviour you have tuned for OLTP for two decades suddenly does not apply. TOAST pressure looks different. HNSW build memory ceilings appear that no GUC can paper over. This talk is a field report from operating pgvector in production: what breaks, why it breaks, and which Postgres internals as TOAST, autovacuum, shared_buffers, parallel index builds react in ways DBAs do not expect when high-dimensional vectors meet realistic write/read patterns generated by LLM-augmented applications. We will walk through three concrete failure modes. First, HNSW build memory cliffs that no GUC tuning can paper over, and the parallel-build trade-offs that benchmarks rarely surface. Second, TOAST pressure and bloat patterns specific to high-dimensional vectors, including the autovacuum behaviour that classical OLTP tuning does not anticipate. Third, recall degradation under churnwhat happens to HNSW graph quality after high-frequency updates, and why EXPLAIN does not show it. For each failure mode, we will look at what the planner is doing, what the index is doing, and what shows up in pg_stat_* and pgvector's own diagnostics. HNSW will be compared against IVFFlat under realistic write-heavy workloads, with numbers. By the end of the session, attendees will be able to: Predict TOAST and vacuum behaviour for vector tables before deploying them Choose between HNSW and IVFFlat using metrics that matter in production, not just benchmarks Configure shared_buffers, work_mem, maintenance_work_mem, and parallel workers for embedding workloads with intent rather than guesswork Recognise the production failure modes that benchmark suites do not catch
