pgvector Index Types: HNSW vs IVFFlat

pgvector offers two approximate-nearest-neighbour (ANN) index types: HNSW and IVFFlat. Both make vector search fast by trading a little recall for a lot of speed, but they work differently and suit different workloads. Here is how to choose.

Why not just scan every row?

Without an index, pgvector compares your query vector against every row — exact, but linear, and far too slow past a few thousand vectors. ANN indexes find almost the nearest neighbours in a fraction of the time. The art is choosing the index and parameters that hit your recall target at your latency budget.

HNSW: the graph index

HNSW (Hierarchical Navigable Small World) builds a multi-layer graph where each vector links to its near neighbours. A search hops through the graph toward the query, checking a small fraction of the data.

CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

• m — links per node; higher means better recall and more memory.
• ef_construction — build-time search width; higher means a better graph, slower build.
• hnsw.ef_search — query-time search width; raise it for recall, lower it for latency.

HNSW gives the best query speed and recall, handles inserts gracefully, and is the right default for almost every production workload.

IVFFlat: the inverted-list index

IVFFlat clusters vectors into lists (via k-means) and, at query time, searches only the closest few lists (probes).

CREATE INDEX ON items USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);
SET ivfflat.probes = 10;

It builds faster and uses less memory than HNSW, but recall depends heavily on lists and probes, and it works best on a static dataset — heavy inserts degrade the clustering until you rebuild.

Side by side

	HNSW	IVFFlat
Structure	Navigable graph	Inverted lists (clusters)
Build time	Slower	Fast
Memory	Higher	Lower
Query speed / recall	Best	Good, tuning-sensitive
Inserts	Handles well	Degrades; rebuild lists
Key params	m, ef_construction, ef_search	lists, probes

Which should you use?

Use HNSW for almost everything — live data, strict latency, high recall. It is what we tune for on managed pgvector.

Use IVFFlat when build time and memory are the binding constraint and your dataset is largely static — for example a one-shot batch index over a fixed corpus where you can afford to rebuild on updates.

You can even keep both index types in the same database for different tables. For parameter tuning, see our HNSW tuning guide, and remember that HNSW's random-read pattern makes NVMe storage a real latency lever.

FAQ

Should I use HNSW or IVFFlat in pgvector?

Use HNSW for most production workloads — it has the best recall and query latency and handles inserts well. Choose IVFFlat only when build time and memory are tight and your data is static enough that occasional rebuilds are acceptable.

Why is my IVFFlat recall low?

Likely too few probes at query time, or lists set poorly for your row count. Increase probes for better recall (at some latency cost), and size lists roughly to the square root of your row count. If the data changes a lot, rebuild the index or switch to HNSW.

Does HNSW use more memory than IVFFlat?

Yes. HNSW's graph stores multiple links per vector, so it needs more memory than IVFFlat's inverted lists. That memory is what buys its superior recall and latency — make sure the index fits in RAM for best performance.

---

More on the pgvector guide, or get started on managed pgvector hosting.