Free tools Windows power users keep installed
One-click scans. No signup required.
To improve pgvector search, first measure approximate results against exact nearest-neighbor search on representative queries. Then tune one source of cost or missed results at a time: index type, search effort, and filtering strategy. HNSW and IVFFlat trade memory and build time differently, while selective WHERE filters can leave approximate scans with too few qualifying rows.
Start with an exact-search baseline
pgvector uses exact nearest-neighbor search by default, and its project documentation describes that path as providing perfect recall. An approximate index can make searches faster, but may return different neighbors. Treat exact results as the comparison set rather than assuming that a faster plan is sufficiently accurate.
As an Amazon Associate I earn from qualifying purchases.
Choose representative query vectors, filters, requested result counts, and a consistent data snapshot. Record the returned row identities as well as latency. To compare against exact search, pgvector documents disabling index scans locally within a transaction:
BEGIN;
SET LOCAL enable_indexscan = off;
SELECT id
FROM items
ORDER BY embedding <=> '[...]'
LIMIT 10;
COMMIT;Replace the example table, column, vector, distance operator, and result count with those used by your application. The operator must match the distance metric and index operator class you intend to evaluate. Keep those inputs and relevant workload conditions unchanged between exact and approximate runs.
#1 Best Overall
For a simple recall-at-k comparison, divide the number of row identities shared by the approximate and exact top-k result sets by k. Also note whether the query returned fewer than k rows. This makes missed neighbors visible without confusing recall with latency.
Inspect the actual plan and buffer activity with EXPLAIN (ANALYZE, BUFFERS) on a representative query. Confirm that the approximate test uses the intended index and compare execution time and buffers with the baseline. A parameter change is not an improvement unless it improves the measured workload in a useful way.
Choose HNSW or IVFFlat for the workload
| Index | Documented tradeoff | When to consider it |
|---|---|---|
| HNSW | Generally better query performance in the speed/recall tradeoff, with slower index builds and greater memory use than IVFFlat. It has no IVFFlat-style training step and can be created before the table contains data. | When query performance is a priority and the available memory and build time are acceptable. |
| IVFFlat | Faster builds and lower memory use than HNSW, but lower query performance in the speed/recall tradeoff. It divides vectors into lists and searches a subset of them. | When a smaller memory footprint or faster build matters and data is available before index creation. |
These are qualitative tradeoffs documented by pgvector, not a guarantee of which index will win for a particular deployment. Compare both against the dimensions that matter to you: recall at the required result count, latency, memory, index-build time, insertion or refresh patterns, and behavior under real filters.
Recommended Free Tools
Rank #2
Tune search effort without guessing
HNSW: raise candidate search effort only when tests justify it
The documented default for hnsw.ef_search is 40. A limited candidate set, dead tuples, and filters can all contribute to receiving fewer results or missing neighbors. Increase search effort when the baseline comparison shows insufficient recall or results, then measure the added latency. For example, set the value for one test transaction with SET LOCAL hnsw.ef_search = 100;; choose a test value based on your measurements rather than treating 100 as a recommended universal setting.
IVFFlat: tune lists at index creation, then probes
IVFFlat should be created after loading some data. The pgvector README gives these starting heuristics for the number of lists: around rows divided by 1,000 for up to one million rows, and around the square root of the row count above one million. They are starting points, not optimal settings for every dataset or query mix.
Start ivfflat.probes around the square root of the list count, then benchmark. More probes search more lists and can improve recall at the cost of speed. The documentation notes that setting probes equal to the number of lists reaches exact nearest-neighbor search; the planner will not use the IVFFlat index in that case. Use the exact-search path as a baseline, not as an assumed way to retain IVFFlat acceleration.
Why filters can return fewer rows
With approximate indexes, pgvector applies filters after scanning the index. If a filter matches only a small fraction of the table, many candidates may be discarded after the scan. The README illustrates this with a condition matching 10% of rows: at the default HNSW ef_search of 40, the average would be four matching rows. That is an illustrative example, not a guarantee for a particular query.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsStarting with pgvector 0.8.0, iterative index scans can keep scanning until enough qualifying results are found or a scan limit is reached. This is useful when filtering leaves too few matches, but more scanning can increase query time and resource use.
Pick a filtering strategy that fits the selectivity
- Selective filter with few qualifying rows: an ordinary index on the filter column may let PostgreSQL find qualifying rows and perform exact nearest-neighbor search efficiently.
- Several filter columns: consider a multicolumn index for the filter conditions.
- A small set of filter values: a partial approximate index may be appropriate for the values that matter.
- Many distinct values: consider partitioning rather than creating a partial index for every value.
- Multiple tenants: a shared approximate index can let one tenant’s vectors affect another tenant’s recall and speed. List partitioning or separate tables can provide isolation.
Measure filtered queries separately from unfiltered ones. A setup that performs well on a broad search may not return enough qualifying neighbors when a tenant, category, or status condition is added.
Use iterative scans carefully
Iterative scans are available starting with pgvector 0.8.0. They can continue searching for more qualifying results up to configured limits. Strict ordering preserves exact distance order; relaxed ordering may improve recall while allowing results to be slightly out of order.
For HNSW, the documented controls include hnsw.max_scan_tuples, which defaults to 20,000, and hnsw.scan_mem_multiplier, which defaults to 1. For IVFFlat, ivfflat.max_probes caps probes during iterative scans. Increasing scan limits may use more time or memory, so test them alongside recall and latency.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When using relaxed ordering but needing final results in strict distance order, pgvector documents restoring the order outside a materialized CTE. Its example requires + 0 in the outer ordering expression on PostgreSQL 17 and later:
WITH relaxed_results AS MATERIALIZED (
SELECT id, embedding <=> '[...]' AS distance
FROM items
WHERE category_id = 123
ORDER BY embedding <=> '[...]'
LIMIT 20
)
SELECT id, distance
FROM relaxed_results
ORDER BY distance + 0;Use the appropriate distance expression, filter, and result count for your query. The materialized result set is ordered after the scan; it does not remove the need to measure whether the scan found enough good candidates.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Consider storage and index-build choices at scale
For a smaller working set, pgvector describes halfvec as a lower-precision storage option. Binary quantization can reduce index size and speed builds at scale; reranking binary-search candidates with the original vectors is a documented way to improve recall. Both approaches involve precision or ranking tradeoffs, so evaluate result quality as well as resource use on representative queries.
For large initial loads, the README recommends bulk loading with COPY and creating indexes after loading. Increasing parallel maintenance workers can speed index creation. In production, CREATE INDEX CONCURRENTLY avoids blocking writes. HNSW vacuuming can take a while; the documented suggestion is to reindex concurrently before vacuuming.
A repeatable tuning loop
- Capture the workload: save representative query vectors, filters, result counts, and data conditions.
- Measure exact results: record result identities, latency, and a representative
EXPLAIN (ANALYZE, BUFFERS)plan with index scans disabled for the exact comparison. - Select an index: test HNSW when its speed/recall tradeoff fits your memory and build constraints; test IVFFlat when lower memory use or faster builds matter and the data can be loaded first.
- Change one setting: tune HNSW search effort or IVFFlat lists and probes, then rerun the same comparisons.
- Test filtered queries independently: check selectivity and evaluate iterative scans, a conventional filter index, a partial index, or partitioning where appropriate.
- Keep only measured improvements: compare recall, rows returned, latency, and plans. PostgreSQL monitoring tools such as
pg_stat_statementsor PgHero can help observe ongoing query behavior. - Revisit settings as conditions change: data volume, filters, concurrency, and latency requirements can alter which settings work well.
The pgvector README documents defaults and sizing heuristics, but does not establish a universal best configuration or workload-specific performance result. Test against your own data and query mix.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
