Vector workloads stress memory, CPU, I/O, WAL, and maintenance. PostgreSQL still needs autovacuum to reclaim dead tuples and protect transaction IDs, ANALYZE for planner statistics, and disciplined index builds. Size shared_buffers, per-operation memory, connection counts, and maintenance_work_mem as one budget; never multiply an attractive setting across uncontrolled concurrency.
shared_buffers is shared cache. work_mem may be used by each sort/hash operation, multiple times per query. maintenance_work_mem supports maintenance and vector index builds; workers and concurrent builds multiply consumption. HNSW also exposes build/search memory-related behavior through extension settings.
Calculate worst-case concurrency before increasing anything. Container memory limits and operating-system page cache matter too.
Updates and deletes create dead tuples under MVCC. Autovacuum reclaims space for reuse and prevents transaction-ID exhaustion; analyze updates statistics. Vector indexes may be costly to vacuum. Upstream pgvector notes that reindexing an HNSW index before vacuum can speed vacuum in some cases, but reindexing has its own locking, disk, WAL, and risk—test and plan it.
Use progress views for CREATE INDEX and VACUUM. After a failed concurrent build, inspect pg_index.indisvalid and clean up the exact invalid index deliberately.
Rehearse a production-sized build on a snapshot. Record duration, peak memory/CPU/I/O, WAL, replica lag, disk headroom, write latency, and cancellation recovery. Generate updates/deletes and prove autovacuum keeps pace without harming SLOs.
Create a maintenance capacity plan from these instance resources, connections, query shapes, table/index sizes, write rates, and build goals [paste]. Calculate memory concurrency, disk/WAL headroom, vacuum monitoring, index-build steps, cancellation recovery, and change windows.
Verification contract: Rehearse on a production-shaped copy and show peak resources plus successful recovery from a canceled concurrent build.