In vector search, how do pre-filtering, post-filtering and filtered ANN traversal differ?

## The problem An approximate nearest-neighbour index is built to answer one question fast: which stored vectors are closest to this query vector. It knows nothing about your metadata. A metadata predicate — tenant, version, ACL, status — has to be reconciled with that search, and *where* you reconcile it is the whole design decision. There are three placements, and they differ in recall, in latency, and in whether scope is guaranteed at all. ## Post-filtering Run the ANN search as normal, get back a candidate list, then drop every candidate that fails the predicate. The index is untouched and any store supports it, including doing it in your own application code. The defect is structural: the candidate list was chosen by similarity alone, so the predicate can eat arbitrarily much of it. Ask for 50 neighbours on a corpus where 2% of documents belong to the requesting tenant and you can plausibly return 3 — and the other 47 in-scope documents that *would* have ranked well were never candidates in the first place. This is a recall failure, not a ranking failure, and it is invisible in the response: you see three plausible passages, not the forty-seven you missed. The usual patch is over-fetching — request 500 to keep 50. That trades latency and post-processing for a probability, not a guarantee, and the multiplier you need depends on a selectivity you generally do not know per query. Post-filtering is defensible when the predicate matches most of the collection (a `status = "published"` filter that excludes 3% of documents), and unwise otherwise. One thing post-filtering does *not* do is leak: rejected documents are dropped before the caller sees them. Its sin is silent under-retrieval. ## Pre-filtering Evaluate the predicate first — usually via a payload index or a bitmap of matching ids — and search only inside the matching subset. Scope is guaranteed and, if you score the subset exhaustively, recall is exact rather than approximate. The cost is proportional to the subset. If the predicate admits ten thousand vectors out of fifty million, brute-force scoring those ten thousand is fast and beats any graph traversal. If it admits forty million, you have re-created the full scan that the ANN index existed to avoid. There is also a subtler version of pre-filtering where the restricted id set is handed to the graph as an allow-list; that keeps the index but can fragment the graph, because the nodes that made two regions of it reachable may not be in the allow-list. ## Filtered traversal The modern default is to push the predicate down into the search itself. The engine traverses its graph or probes its partitions as usual, evaluates the payload predicate on nodes it visits, and admits only matching nodes to the result heap — while still traversing *through* non-matching nodes so the graph stays navigable. Some engines additionally build extra links so that same-payload neighbours remain connected under common filters. The result is what you actually wanted: up to a full k of in-scope neighbours, from one query, with no over-fetch multiplier to tune. The cost is that the traversal does more work as the predicate gets more selective — it must visit more nodes before it has collected k matching ones. At extreme selectivity that degenerates, which is why engines typically fall back to exhaustive scoring of the matching subset once the estimated match count drops below a threshold. As of mid-2026, filtered traversal plus an automatic brute-force fallback is standard behaviour in mainstream vector databases rather than something you implement yourself. ## Choosing Selectivity is the deciding variable, and it is a property of the query, not of the system. Predicates that admit most of the corpus: post-filter with light over-fetch is fine. Predicates in the broad middle: filtered traversal. Predicates that admit a tiny slice: pre-filter and score exhaustively. Two caveats sit above the performance argument. First, a hard scope requirement — tenant, ACL — must be enforced by the engine on every query path, not by whichever strategy happens to be selected; post-filtering satisfies that only if the filtering code is inside the trusted path and never skipped. Second, none of the three guarantees *exactly* k results: when fewer than k documents match at all, you get what exists, and the pipeline needs a defined behaviour for the empty and short cases rather than silently presenting a thin context window as a complete one.