pgvector Iterative Scan in Production: strict_order vs relaxed_order and max_scan_tuples

If you run vector search in PostgreSQL with metadata filters, pgvector 0.8 on PostgreSQL 17 solves the post-filtering trap that silently dropped rows below your LIMIT. But turning on iterative scans without tuning the scan mode and safety bounds can spike latency. Here is how strict_order, relaxed_order and max_scan_tuples behave in production.

#The problem iterative scans solve

In an earlier write-up on the pgvector filtering trap, I showed why a query with LIMIT 10 and a selective WHERE filter often returns only 3 or 4 rows. An approximate nearest neighbor index explores the vector graph first, collects candidates up to hnsw.ef_search (default 40), and applies your SQL filter afterward. If your filter matches only 10% of rows, roughly 4 rows pass.

Before PostgreSQL 17, the only fixes were raising ef_search to large numbers, creating partial indexes for fixed filter values, or partitioning tables. PostgreSQL 17 added iterator support to index access methods, allowing pgvector 0.8 to resume scanning the index incrementally whenever the filter discards candidates.

#Two scan modes: strict_order vs relaxed_order

You control the scan behavior through the hnsw.iterative_scan session variable:

[object Object]

The difference between the two active modes comes down to distance guarantees:

• strict_order: Guarantees that every returned row is strictly closer than any row that could have been found later. To prove this, pgvector expands its search radius before yielding the next batch. On highly selective filters (matching 1% to 5% of your table), this requires scanning substantially more graph nodes.
• relaxed_order: Yields matching rows as each graph neighborhood is visited. The overall list is roughly ordered by distance, but a row from iteration two might have a slightly smaller distance than a row from iteration one. For RAG retrieval where all top candidates feed into an LLM context window, this slight relaxation cuts query latency by 60% to 70% with negligible recall loss.

#Stopping runaway scans with max_scan_tuples

The biggest operational danger with iterative scans is a filter that matches very few rows, or zero rows. Consider this query:

[object Object]

If acme_corp has only two archived documents in a table of two million rows, an unconstrained iterative scan will inspect every single vector in the index searching for the remaining eight rows. This turns a 5-millisecond vector query into a multi-second table scan that monopolizes CPU cores.

To prevent this, pgvector provides hnsw.max_scan_tuples (default 20,000):

[object Object]

#Production decision matrix

Iterative scans are powerful, but they are not the right tool for every access pattern. Here is how to choose between index strategies:

#How to verify in EXPLAIN plans

Run EXPLAIN (ANALYZE, BUFFERS) on your query. In PostgreSQL 17 with iterative scans enabled, the execution node explicitly reports the iterative behavior and tuple count:

[object Object]

Notice Tuples Processed: 44 and Rows Removed by Filter: 34. The index scanned 44 candidates to satisfy the 10-row limit, rather than giving up after the first batch.

#Related resources

• pgvector: HNSW vs IVFFlat and the Filtering Trap
• Runaway LLM Agent Costs: Budgets, Step Limits and Kill Switches
• FAQ: Should I use HNSW or IVFFlat in pgvector?