Filtered Vector Search: What ACORN Fixes, and What Fixes ACORN

Filtered vector search breaks when metadata filters turn a healthy nearest-neighbor graph into scattered islands. HNSW’s m parameter controls how many links each point gets. At Qdrant’s default m=16, the one-million-point collection benchmarked below averaged about 21 links per node on layer 0. Filter out 96% of the points and fewer than one link per node survives on average, so traversal can get stranded before it reaches the true nearest matches.

Qdrant repairs that damage in two places. Filterable HNSW adds extra edges at index time; ACORN steps through neighbors of neighbors at search time. Both run on the same collection. ACORN earns its cost where the extra edges don’t reach: values too common to link, AND filters no single field’s edges cover, and payload fields the build skipped silently.

This benchmark runs on a single Qdrant instance and compares four of Qdrant’s own search strategies over four builds.

The Two ACORNs

The ACORN paper (Patel et al., SIGMOD 2024) describes two algorithms. Its headline claim of “2-1,000x higher throughput at a fixed recall” belongs to ACORN-gamma, which expands neighbor lists during index construction at 8.8x to 33.1x plain HNSW’s build time in the paper’s own table.

ACORN-1 is lighter. It builds a standard HNSW graph, then checks neighbors of neighbors at search time where direct neighbors fail the filter. Qdrant implements ACORN-1 as a query parameter you opt into per request, with no index-time changes.

The Graph Qdrant Builds Instead

Filterable HNSW, which our co-founder Andrey Vasnetsov described in 2019, builds the repair into the index. When a payload field, the metadata attached to each point, is indexed, Qdrant adds extra HNSW edges between points that share a value in that field, so a filtered query keeps a connected graph to traverse. Qdrant gives those edges to payload fields at index time, and not every field earns them.

Those edges cost build time. On our one-million-point collection, the HNSW index built in 116 seconds without them and 507 to 652 seconds with them, 4.4x to 5.6x the cost. That range covers two builds at identical settings, so it is build-to-build variance. Both figures are index build time, with ingest excluded.

Qdrant builds those edges per payload field, never per combination, so an AND filter lands on an intersection that no single field’s edges cover. ACORN-1 covers that gap and pays at query time instead of build time. Qdrant’s query planner chooses automatically between ACORN, full scan, retrieval straight from the payload index, and filterable HNSW.

The Benchmark

The benchmark runs on one million deep-image-96 vectors, 96-dimensional image embeddings from the ANN-benchmarks suite. Keyword filters match from 20% of the points down to 0.012%. Recall@10 is scored against exact brute force over 500 queries per filter, and latency is mean server-side query time.

We tested four strategies:

1. Plain graph: standard HNSW with no extra edges.
2. Plain graph + ACORN: the same graph with ACORN forced on.
3. Filterable HNSW: the default build with extra edges.
4. Planner + ACORN: Qdrant’s default query planner, free to route each query to ACORN, full scan, or the payload index.

Every filter matches one keyword value on a payload field. The collection carries seven such fields, holding 5, 10, or 100 distinct values each.

Single Filters: Extra Edges Win

hnsw_ef, shortened to ef below, is the number of candidates the search evaluates, so raising it improves recall and slows the query. Selectivity is the fraction of points that pass the filter.

Why Some Payload Fields Get No Extra Edges

Qdrant builds extra edges by walking the values of each indexed payload field. For each value it finds the points that share it and links them, so a query filtered to that value still has a graph to traverse.

A value shared by more points than a size cap gets no extra edges, because the main graph should already keep that many points connected. Qdrant derives that cap per segment, the slice of a collection that has its own index. The formula is point count divided by average links per node, times four.

Double Filters: The Intersection Gap

The same benchmark at hnsw_ef=64, now with an AND filter over two keyword fields.

ACORN on a Normal Collection

This is the default configuration: extra edges, the default threshold, and the planner free to choose the graph or the payload index in both columns.

What to Measure on Your Own Collection

Measure recall for each filter shape you serve. Start with the ones most likely to break: values covering roughly a fifth of the collection or more, and AND combinations of them. Create a payload index on every field you filter on, and leave ACORN off to start. Then sample a few hundred real queries per filter shape. Compare the recall gain with the latency cost. Turning it on never lowered recall in any of our runs, so if you are unsure, the cost of leaving it on is latency.

Further Reading

• ACORN (Patel et al., SIGMOD 2024)
• RACORN-1
• PostgreSQL ACORN study
• Filterable HNSW
• Reproduction kit