Exact vector search compares your query against every stored vector and returns the true nearest ones. Approximate indexes such as HNSW and IVFFlat skip most vectors to answer faster, and may occasionally miss a true neighbour. Start exact, and switch only when measured speed demands it.
What exact search does
Brute force. For each query, compute the distance to every vector and sort. The pgvector README describes exact search as the default and says it provides perfect recall. For a small or medium index this is often fast enough, and it has no tuning knobs and no surprises.
Why approximate indexes exist
Cost grows with the number of vectors. At some point scanning everything per query is too slow. Approximate nearest neighbour indexes build a structure so a query visits only a fraction of the data.
The price is recall. Recall means: of the true top results, what share did the index return? The pgvector documentation notes that adding an approximate index trades some recall for speed, and that results can differ from exact search.
HNSW
HNSW builds a multilayer graph. A query enters at the top, hops towards the query vector, and descends. According to the pgvector documentation, HNSW gives a better speed and recall trade-off than IVFFlat, but builds more slowly and uses more memory. It does not need a training step, so it can be created on an empty table.
IVFFlat
IVFFlat divides vectors into lists and searches only the lists nearest the query. The pgvector documentation says it builds faster and uses less memory than HNSW but gives lower query performance, and it should be created after the table has data, since the lists are derived from existing rows.
Choosing
- Perfect recall, simple setup: Exact.
- Best speed and recall balance, memory is available: HNSW.
- Fast builds and low memory: IVFFlat.
- Frequent rebuilds of a changing index: Test both, build time matters.
Check recall on your own data
Do not trust defaults. Take a sample of queries, run them exact and approximate, and compare the result lists. If the approximate index returns nearly the same top ten, fine. If it drops files you need, adjust the index parameters or go back to exact.
This is a retrieval quality question, so tie it to a small test set, as described in how to evaluate a code search system.
Filters change everything
Searching only within one repository or one team's documents is a filter applied alongside the vector search. Filtering and approximate indexes interact, and a filter that removes most candidates can leave you with few results. Test filtered queries specifically, especially if you enforce permissions this way.
Other tools
Faiss, a similarity search library, lists exact search as a baseline, along with HNSW and compressed representation methods, so the same trade-off appears there. Which store to use is covered in Postgres with pgvector or a dedicated store.
Quick check
Does approximate search make answers wrong?
It can make retrieval miss a relevant item, which then never reaches the model. The model does not know it was missed, so measure recall.
Which should a small team pick first?
Exact search. Add an index only after you see slow queries.
Sources
Last reviewed: 19 October 2026.
