pgvector ships two index types. Which should be your default reach in 2026, and why was it added later than the other?

**pgvector** is the Postgres extension that adds vector data types and ANN index support. As of 2026 it ships two ANN index types: **IVFFlat** and **HNSW**. **IVFFlat** came first (pgvector 0.4.0 in 2022). It is a partition-based index: k-means clusters the vectors into `lists` partitions; queries probe the closest `probes` partitions. It was the natural first index because k-means + inverted lists fits cleanly into Postgres' generic access-method framework (the same framework that powers GIN and GiST). **HNSW** was added in pgvector 0.5.0 (mid-2023). It is a graph-based index: each vector is connected to a few of its nearest neighbors in a hierarchical small-world graph. It was harder to implement inside Postgres' access-method API because the graph maintenance under MVCC and WAL needs care, but the recall vs latency profile is materially better than IVFFlat for most workloads. **Why HNSW is the default reach in 2026:** - Higher recall at the same latency, especially at small candidate budgets. - No training step. IVFFlat needs a representative sample at build time; HNSW does not. - Inserts do not degrade recall the way they do in IVFFlat. You can keep adding vectors without periodic rebuilds. - It matches what every dedicated vector DB (Pinecone, Qdrant, Weaviate, Milvus) reaches for first. **When to still pick IVFFlat:** smaller memory footprint matters more than per-query recall, your write pattern is batchy (so periodic reindex is fine), and you have a large representative sample at build time. For modern RAG workloads with continuous inserts, HNSW is the right answer.

**HNSW is the 2026 default in pgvector.** Here's the history and the reasoning. *IVFFlat (pgvector 0.4.0, 2022).* The first ANN index in pgvector. K-means partitions the vectors into `lists` clusters; queries probe `probes` of them. The implementation is short because k-means + inverted lists maps cleanly to Postgres' generic access-method API. The catches: (1) the index needs a representative training sample at build-time, so building on an empty or growing table gives a poor partitioning; (2) inserts under the trained partitioning gradually skew the cluster sizes and degrade recall until the next `REINDEX`; (3) recall ceiling is lower than HNSW at the same latency budget. *HNSW (pgvector 0.5.0, mid-2023).* Hierarchical Navigable Small World graph. Each vector is linked to its M nearest neighbors at the bottom layer; higher layers are sparser samples. Search is a greedy walk. The implementation was harder for pgvector to ship because: - The graph must be maintained correctly under MVCC (multi-version concurrency control), which means inserts have to handle visibility correctly. - WAL (write-ahead log) integration is non-trivial; graph mutations must be replay-safe. - Concurrent inserts need to update overlapping graph edges without corruption. IVF's static `lists` made these problems trivial; HNSW's dynamic graph forced pgvector to invest in extension-level coordination primitives. *Why HNSW wins in 2026.* 1. **Recall vs latency profile.** HNSW achieves recall@10 > 0.95 at sub-10ms latency on tens of millions of vectors. IVFFlat needs `probes` set high enough that the latency advantage evaporates. 2. **No training step.** HNSW builds incrementally as you insert. IVFFlat needs a sample large enough that k-means converges; a poorly-trained IVFFlat is just bad. 3. **Inserts don't degrade recall.** New vectors find their place in the existing graph. IVFFlat partitions cannot move once trained, so insert skew degrades recall over time. 4.