Hierarchical Navigable Small World (HNSW) builds a multilayer proximity graph. Search enters sparse upper layers, navigates toward the query, then explores a denser neighborhood. HNSW usually offers a strong speed–recall tradeoff and needs no training step, but consumes memory, builds more slowly, increases write work, and still requires measured tuning.
Higher values can improve recall but consume more build/query time and memory. Defaults and available settings are version-specific; inspect your installed pgvector documentation.
CONCURRENTLY reduces blocking of writes but takes longer, cannot run inside a transaction block, and has failure states you must inspect. For an empty new table, a normal build before traffic may be simpler.
Keep setting and query on the same transaction/connection. Sweep several values, recording exact recall@k, p50/p95 latency, CPU, buffers, and returned rows for each filter slice.
HNSW builds faster when its graph fits in maintenance_work_mem, but setting that too high across concurrent maintenance can exhaust server memory. Monitor the server, limit parallel build concurrency, and use progress views where available. Increase memory only from a capacity calculation.
Confirm index validity in pg_index, size via pg_relation_size, and usage with EXPLAIN (ANALYZE, BUFFERS). Compare at least five ef_search values against exact results on held-out queries. Test inserts and deletes after the build and observe write latency.
Design an HNSW tuning experiment for [rows, dimensions, metric, query rate, filters, latency/recall goals]. Include build matrix, ef_search sweep, exact baseline, slice metrics, memory budget, concurrent-build procedure, write impact, and rollback.
Verification contract: Choose parameters from a plotted speed–recall curve and operational budget, not a copied setting.