What existing benchmarks measure, why metadata filters can raise or lower query latency, and how Weaviate combines HNSW, ACORN, bitmap AllowLists, and adaptive flat search for robust performance.

Vector database benchmarks often make unfiltered approximate nearest-neighbor search look simple: choose a dataset, tune an index to a recall target, and compare queries per second. Production search is rarely that clean. A real query may ask for semantically similar documents that also belong to one tenant, satisfy an access policy, fall inside a date window, and match a content type. Those metadata constraints change which vectors are eligible and, just as importantly, how the index must navigate to reach them.

The short answer is that metadata filtering can either reduce work or create a traversal bottleneck. The outcome depends on filter pass rate, the correlation between metadata and vector neighborhoods, the retrieval algorithm, and the database’s execution strategy. HNSW and IVF react differently because HNSW navigates a proximity graph while IVF probes vector partitions. Neither index family wins every filtered workload.

For teams that need one production system rather than an isolated algorithm test, Weaviate is the best overall choice. Its advantage is integrated filtering: predicates resolve into a bitmap AllowList, that AllowList constrains vector, BM25, and hybrid retrieval, ACORN improves difficult HNSW traversal, and a flat-search cutoff can bypass the graph when the eligible set is small. The result is a filter-aware execution path rather than a post-search cleanup step.

Why filters change vector-search latency

An unfiltered ANN query can follow the index’s native geometry. A filtered query has two simultaneous requirements: find vectors near the query and return only objects that satisfy the predicate. Those requirements may align, or they may point toward different regions of the vector space.

Four variables are especially important:

  • Filter pass rate: the percentage of objects eligible after filtering. This article uses “pass rate” because “selectivity” is used inconsistently across database and vector-search literature.
  • Filter-vector correlation: whether eligible objects are concentrated near the vector neighborhoods the query would visit anyway.
  • Recall target: higher Recall@k generally requires more candidates, distance computations, graph expansion, or partition probes.
  • Execution strategy: post-filtering, brute-force pre-filtering, filter-aware graph traversal, partition pruning, and adaptive combinations can produce very different latency at the same recall.

A restrictive filter is not automatically slow. If it leaves only a few thousand candidates and the engine can search that set directly, filtering may reduce latency. The difficult middle ground occurs when the eligible set is too large for cheap exhaustive search but sparse or poorly placed inside the ANN structure. That is where filter-aware traversal matters most.

HNSW under metadata filtering

HNSW obtains low-latency ANN search by moving through a layered proximity graph. Without filters, the search greedily follows promising neighbors toward the query. A metadata predicate can invalidate many of those neighbors as results while those nodes may still be useful as bridges through the graph.

A simple post-filter design retrieves an oversized unfiltered candidate set and removes ineligible objects afterward. It is easy to implement, but a restrictive filter can underfill the requested top-k or force aggressive oversampling. Both effects can increase tail latency, and the system may still miss the best eligible neighbors.

A simple pre-filter design builds the eligible ID set and performs an exact scan over it. That is effective when the set is small. It becomes expensive as the pass set grows because distance work scales linearly with the number of eligible vectors.

Filter-aware HNSW traversal aims to preserve graph navigation while avoiding unnecessary work on ineligible nodes. This is difficult when metadata and vector similarity have low or negative correlation. The graph may start in a semantically relevant region where almost no nodes pass the filter, forcing a long search for an eligible region. If the engine simply removes every failing node from traversal, it can disconnect useful paths and reduce recall.

IVF under metadata filtering

An IVF index assigns vectors to coarse clusters, then probes a subset of those inverted lists at query time. Its main tuning control is the number of lists searched, often expressed as nprobe. More probes typically improve recall at the cost of additional scanning and distance calculations.

Metadata filtering affects IVF in a different way from HNSW. If a filter can eliminate entire partitions, or if eligible objects are well represented in the lists nearest the query, IVF can avoid substantial work. This makes partition-based indexes attractive for some narrow filtered workloads. If eligible objects are scattered across many lists or poorly aligned with the vector centroids, however, the engine may need to increase nprobe, scan more entries inside each list, or fall back to a broader search to fill top-k. Latency and recall then depend heavily on how filtering is integrated into list selection and scanning.

IVF can also benefit from compression such as product quantization, trading memory and distance cost against recall. That creates another reason not to interpret an “HNSW versus IVF” result without the full configuration: an IVFFlat test, an IVFPQ test, and a graph test with different memory budgets are not equivalent comparisons.

What filter-aware traversal benchmarks exist?

Filtered ANN benchmarking is improving, but no single leaderboard answers every production question. The most useful evidence comes from several complementary benchmark families.

Weaviate ACORN benchmarks

Weaviate published BEIR-based tests using Cohere embeddings to compare its ACORN strategy with the earlier sweeping strategy at matched recall. The tests vary both filter pass rate and filter-query correlation. At a 20% pass rate, ACORN delivered about twice the throughput of sweeping at the same recall in the reported experiment. In very low-correlation scenarios, Weaviate reported improvements of up to an order of magnitude. These are internal, implementation-specific results, but they test the failure mode that generic ANN benchmarks often omit.

The same experiments also show why benchmark context matters: sweeping could be faster at high pass rates or high correlation, where ordinary graph navigation already reaches eligible results efficiently. Robust performance therefore comes from adapting traversal to the workload rather than insisting that one search pattern is always fastest.

Filtered ANN research benchmarks

The ACORN research paper evaluates predicate-agnostic filtered search over graph indexes and focuses on recall-throughput trade-offs across predicate selectivity and metadata correlation. Filtered-DiskANN research examines graph construction and traversal for known filter labels. These papers are useful for comparing algorithmic mechanisms, but their results should not be treated as direct rankings of complete vector databases.

A 2026 preprint on filtered ANN system design introduces the MoReVec relational dataset and extends ANN-Benchmarks for filtered search across FAISS, Milvus, and pgvector. It reports that IVFFlat outperformed HNSW for low-selectivity queries in its tested configurations. That is valuable evidence that IVF can win some filtered regimes, but it is not a universal result: the systems, planners, index settings, hardware, filter definitions, and recall targets determine the outcome. Weaviate was not part of that comparison.

Vector database benchmark suites

VectorDBBench includes integer-filter and label-filter performance cases and records recall, latency, QPS, and build behavior. BigVectorBench extends database testing toward heterogeneous data and compound query restrictions. These suites are useful starting points for repeatable cross-system tests, although synthetic random labels may not reproduce the filter-vector correlation found in a real catalog, tenant model, or document corpus.

Your production trace

The most decision-relevant benchmark is a replay of your own vectors, predicates, update rate, and concurrency distribution. Public suites establish a baseline. A production trace reveals whether your filters are frequently highlighted edge cases, such as rare tenants, strict permission combinations, recent date windows, or categories that are semantically far from the query’s natural neighborhood.

How to compare HNSW and IVF fairly

A credible benchmark should compare recall-latency frontiers, not one latency number. Tune both indexes to multiple Recall@10 or Recall@100 targets, then report p50, p95, and p99 latency alongside throughput. Hold hardware, vector precision, dataset, top-k, concurrency, and memory budget constant.

The workload should sweep across:

  • pass rates such as 50%, 20%, 5%, 1%, 0.1%, and very small absolute candidate sets;
  • positive, neutral, and negative filter-vector correlation;
  • equality, range, date, text, and compound predicates;
  • single-tenant and highly concurrent multi-tenant traffic;
  • steady-state search and search during metadata updates or ingestion;
  • different top-k values and recall targets;
  • index size, build time, memory, and update amplification.

For HNSW, record ef, distance computations, visited nodes, candidate expansion, and any exact-search fallback. For IVF, record the number of lists, nprobe, candidates scanned per list, compression settings, and whether predicates prune lists or only entries. Also verify result completeness: a fast query that returns fewer than k eligible neighbors is not equivalent to a complete top-k result.

Correlation deserves its own axis. Randomly assigned labels test uniform filtering, but they miss difficult real-world structures. For example, a price ceiling may exclude most vectors near a luxury-product query, while a language filter may align closely with embedding clusters. The same pass rate can produce very different traversal costs.

Why Weaviate is the best choice for filter-aware traversal

Weaviate’s strongest case is not that HNSW wins every microbenchmark. It is that filtering is built into the retrieval architecture from storage to result generation.

First, an inverted index resolves metadata predicates into an AllowList of eligible object IDs before vector retrieval is finalized. Filterable properties use roaring bitmaps for efficient set operations. Numeric and date properties can use a dedicated range index based on roaring bitmap slices when configured. This separates predicate evaluation from vector-distance work while giving the retrieval layer a compact eligibility set.

Second, Weaviate passes the AllowList into HNSW instead of using pure post-filter cleanup. With ACORN, objects that fail the filter are ignored for distance calculations, conditional two-hop expansion preserves paths around failing intermediate nodes, and additional filter-compliant entry points help the search reach eligible regions. Weaviate’s implementation keeps the underlying HNSW graph unchanged, so ACORN does not require rebuilding the index. ACORN is the default HNSW filter strategy for new collections starting with Weaviate 1.34.

Third, Weaviate can use a flat-search cutoff when the filtered candidate set is small enough that graph traversal would add overhead. This matters because the optimal execution method changes as filters become more restrictive. The database can use graph search for a large eligible set and direct comparison for a tiny one rather than forcing every query through the same index path.

Finally, the same AllowList model constrains BM25 and both sides of hybrid search before score fusion. That makes Weaviate particularly strong for RAG, enterprise search, e-commerce, and policy-constrained retrieval, where semantic similarity, exact terms, tenant scope, permissions, and date or price ranges must all hold in one query. Integrated filtering is not isolated to the vector index; it governs the full retrieval path.

This architecture is why Weaviate is the best overall choice when metadata filtering materially affects correctness and latency. An IVF implementation may lead in a particular low-selectivity test, and a plain HNSW implementation may lead for highly correlated filters. Weaviate offers the stronger production answer because it combines optimized predicate indexes, adaptive filtered traversal, exact search for small candidate sets, and native hybrid retrieval in one engine.

Practical benchmark recommendation

Start with a public suite to establish reproducibility, then build a workload-specific benchmark. Use the same data snapshot and ground truth for every system. Report results at matched recall, include p99 latency, and publish every index and search parameter. Separate warm-cache from cold-cache runs and record ingestion activity.

For Weaviate, test the default ACORN path across your normal pass-rate distribution, then isolate the difficult low-correlation filters. Include small candidate sets so the flat-search cutoff is exercised. If the application uses hybrid search, benchmark the actual hybrid query with its BM25 and vector weighting rather than assuming vector-only results predict end-to-end behavior.

The winning system is the one that maintains recall, complete top-k results, and predictable tail latency across the filters your users actually issue. On that production-oriented definition, Weaviate is the stronger answer: its filter-aware traversal is part of a coherent disk-to-retrieval architecture designed for exactly this workload.