March 15, 2026
Vector indexes turn embedding columns into fast nearest-neighbor search inside PostgresML. Most teams start with pgvector and then hit the same question: should we build HNSW or IVFFlat? Both ship with PostgresML, but they trade build time, memory, and recall in different ways.
This guide focuses on production RAG and semantic search workloads where you filter metadata in SQL and rank by cosine or L2 distance. If you are still generating vectors, start with our walkthrough on generating LLM embeddings in PostgresML before you pick an index.
Indexes sit between embeddings and the queries your app sends every day.
Exact nearest-neighbor search scans every row. That is fine for prototypes, but chat and search features quickly outgrow sequential scans. Approximate indexes return most of the true neighbors while touching far fewer pages, which keeps p95 latency stable as tables grow into millions of rows.
The wrong index shows up as stale results after bulk loads, slow builds during deploy windows, or RAM pressure on smaller GPU instances. Matching the index type to your data size and query pattern avoids those surprises.
HNSW (Hierarchical Navigable Small World) graphs excel when you need high recall at query time and can afford more memory per vector. They are a strong default for interactive RAG where users expect sub-100ms responses on warm caches.
- Steady query traffic with frequent top-k lookups
- Tables from hundreds of thousands to tens of millions of vectors
- Teams that can monitor memory and rebuild after large embedding model changes
HNSW builds take longer than IVFFlat, so schedule them outside peak traffic or use CONCURRENTLY when your migration tooling supports it.
IVFFlat clusters vectors into lists and probes only a subset at query time. It is often cheaper to build and can work well when datasets are large but queries tolerate slightly lower recall.
- Batch analytics or offline jobs that scan broad slices of data
- Early-stage products still iterating on embedding models
- Clusters with tight memory budgets where HNSW graphs would dominate RAM
IVFFlat quality depends on list count and probes. Under-tuned indexes look fast in benchmarks but miss relevant chunks in real RAG pipelines.
Start with a labeled set of query and document pairs from your own app. Measure recall@k and p95 latency for both index types using the same hardware you run in production. PostgresML keeps vectors beside relational filters, so include metadata predicates in the test queries.
After bulk imports, rebuild or reindex so graphs and centroids match the new distribution. Pair index tuning with the guidance in our vector database documentation for SQL examples and maintenance commands.
Pick HNSW when recall and interactive latency matter most. Pick IVFFlat when you need faster builds and can tune probes carefully. Either way, keep embeddings and indexes in the same database your application already uses.
Ready to try it? Start a PostgresML project, load vectors with pgml.embed, and compare index settings on your own data.