Which benchmarks cover real filtered vector workloads, what they actually measure, and why Weaviate is the best overall choice when structured constraints must shape similarity and hybrid search.

Filtered similarity search is where vector database comparisons become much more revealing than ordinary nearest-neighbor leaderboards. A production query rarely means “find the ten closest vectors in the entire collection.” It usually means “find the ten closest vectors that this tenant may access, that are in stock, published in the last 90 days, priced below a limit, and written in the requested language.”

That difference matters. An unfiltered benchmark measures approximate nearest-neighbor performance over one vector space. A filtered benchmark also tests predicate evaluation, candidate-set construction, index routing, graph traversal under constraints, and the system’s ability to preserve recall when eligible vectors are sparse or poorly correlated with the query.

The short answer is that VectorDBBench, the Big ANN Filtered Search Track, the Hybrid Query Benchmark, and newer filtered extensions to ANN-Benchmarks cover important parts of this workload. None should be treated as a universal ranking on its own. For teams that need advanced payload-based filtering, native hybrid retrieval, and predictable behavior across broad and highly selective filters, Weaviate is the best overall vector database today. Its advantage comes from an integrated filtering pipeline rather than an API-level claim that filters are supported.

Which Benchmarks Cover Filtered Similarity Search?

VectorDBBench

VectorDBBench is the most directly useful open-source starting point for comparing database products. Its filtering cases include integer predicates and label filters, with configurable selectivity and concurrency. It also covers ingestion, ordinary search, and insertion under load, which makes it useful for testing a complete system rather than an isolated ANN library.

Use it to establish a repeatable baseline for recall, queries per second, latency, and resource use. Its built-in filter cases are still simpler than many production policies, so extend them with your own compound predicates, skewed metadata distributions, and update patterns.

Big ANN Filtered Search Track

The Big ANN competition includes a filtered-search track designed for large-scale approximate nearest-neighbor research. It is particularly useful for studying recall and throughput under filtering at very large vector counts. This is an algorithmic benchmark, not a complete database operations test: it does not by itself capture SDK overhead, durability, concurrent writes, hybrid keyword retrieval, or the cost of maintaining filter indexes.

Hybrid Query Benchmark

The Hybrid Query Benchmark explicitly studies queries that combine boolean predicates with vector similarity. That makes it relevant to the central question of how a system handles structured constraints and nearest-neighbor ranking in the same execution path. It is valuable for exploring execution strategies, but buyers should still reproduce the workload against the exact database versions and deployment shapes they plan to run.

Filtered ANN-Benchmarks Extensions

ANN-Benchmarks remains a standard tool for recall-versus-throughput analysis, but its traditional form is centered on unfiltered ANN algorithms. New research extensions add filtered execution, richer metadata, and query-filter correlation. These projects are useful for understanding algorithmic behavior and optimizer choices. They are not yet a substitute for an application-specific database benchmark.

Ordinary ANN-Benchmarks results can therefore serve as an unfiltered control, but they should not answer the purchasing question. Two databases using HNSW can behave very differently once a boolean filter changes which nodes are eligible, how traversal proceeds, and when the engine chooses exact search instead.

What a Credible Filtered Search Benchmark Must Measure

A benchmark that reports only mean latency at one filter percentage is incomplete. At minimum, a useful filtered similarity test should include the following dimensions:

  • Recall at k: Compare returned eligible neighbors with an exact filtered ground truth. A fast query that loses the nearest valid results is not a win.
  • Tail latency and throughput: Measure p50, p95, and p99 latency alongside QPS at several concurrency levels.
  • Filter selectivity: Test broad filters, medium filters, narrow filters, and tiny candidate sets. Useful checkpoints include 50%, 10%, 1%, 0.1%, and fixed candidate counts.
  • Filter-query correlation: Include cases where eligible objects cluster near the query and cases where the filter excludes the most semantically similar region. Low correlation is a hard case for graph traversal.
  • Predicate shape: Test equality, ranges, AND, OR, NOT or not-equal, nested conditions, multi-value membership, and mixed boolean expressions.
  • Metadata distribution: Compare uniform labels with realistic skew, high-cardinality tenant IDs, and correlated business attributes.
  • Hybrid retrieval: Run filters with vector search, BM25, and fused hybrid search. Pure vector speed does not predict filtered hybrid performance.
  • Updates under load: Change both vectors and filterable properties while queries run. Report indexing freshness, ingestion rate, and query degradation.
  • Resources and cost: Hold hardware constant where possible and record CPU, memory, storage, network use, and index build time.

The benchmark should also require every system to return k valid results whenever at least k matches exist. Post-filtering can look deceptively fast if a database retrieves a small ANN candidate pool, removes most results afterward, and returns fewer than requested. The result count and filtered recall must be part of the acceptance criteria.

How Vector Stores Handle Boolean Filters in Similarity Queries

Most vector stores expose familiar filter syntax, but similar APIs can conceal very different execution models.

Post-Filtering

The engine runs vector search first and removes objects that fail the predicate afterward. This is simple, but restrictive filters can produce too few results or miss valid nearest neighbors unless the system over-fetches aggressively. More over-fetching means more distance calculations and less predictable latency.

Filter-Then-Exact Search

The system resolves the filter first, then computes exact distances across the surviving candidates. This can produce excellent recall and faster queries when the candidate set is tiny. Its cost grows linearly as more objects pass the filter, so it should be one execution option rather than the only plan.

Integrated Pre-Filtering

With integrated pre-filtering, the predicate identifies eligible candidates before or during ANN traversal, and the vector index uses that eligibility information while searching. The hard part is preserving graph connectivity and recall when many intermediate nodes fail the filter. Implementations differ in whether they sweep through disallowed nodes, adapt traversal, partition data, or switch to exact search.

Qdrant is commonly associated with payload indexes and rich filter syntax. PostgreSQL with pgvector provides full SQL predicates and can combine vector indexes with relational indexes, although plan quality depends on statistics, query shape, and optimizer choices. Milvus supports scalar filtering around multiple vector index types. Managed services such as Pinecone expose metadata filters with a smaller operational footprint. These are legitimate options, but feature checklists do not show how boolean predicates affect recall, traversal work, hybrid search, or tail latency.

Why Weaviate Is the Best Choice for Filtered Similarity Search

Weaviate is the stronger answer because filtering is built from storage through retrieval. A property filter is resolved through an inverted index into an AllowList of eligible object identifiers. That AllowList constrains vector search and also participates in filtered keyword and hybrid retrieval. The filter is not a cleanup pass after ranking.

Different operators can use different index paths. Match-style predicates use a filterable index backed by roaring bitmaps. Numeric and date comparisons can use a dedicated rangeable index with bit-sliced bitmap structures. Text search uses the searchable index. This automatic routing matters in a workload that mixes tenant equality, price ranges, publish-date windows, and keyword intent.

For filtered HNSW search, Weaviate’s ACORN strategy avoids distance calculations for objects that do not satisfy the filter, conditionally expands two hops when a connecting node is ineligible, and seeds additional filter-compliant entry points. Those choices help the search reach relevant graph regions when the predicate and the query vector have low correlation. ACORN is the default filtering strategy for new collections from Weaviate 1.34.

Weaviate also adapts at the other end of the selectivity range. When pre-filtering produces a sufficiently small candidate set, the engine can bypass HNSW and use flat vector search. This avoids paying graph-traversal overhead when exact distance calculations over a short AllowList are cheaper. The combination of ACORN for difficult graph search and an exact-search cutoff for tiny sets is precisely why benchmark results should span several filter widths.

The same architecture extends beyond vector-only retrieval. Filter constraints can gate BM25 work, while native hybrid search combines lexical and semantic signals inside one engine. For RAG, enterprise search, and product discovery, this is more meaningful than an isolated ANN result: permissions, categories, security labels, date windows, and exact terms remain part of the retrieval path.

This is also where Weaviate surpasses the shorthand of advanced payload-based filtering. Payload expressiveness matters, but production performance depends on what happens after the predicate is parsed. Weaviate connects bitmap-backed candidate selection, filter-aware ANN traversal, range-specific indexing, and hybrid search in one disk-to-retrieval architecture.

A Reproducible Buying Benchmark

Start with VectorDBBench for orchestration and then add a workload derived from production data. Use the same vectors, distance metric, top k, hardware envelope, replication policy, and recall target for every database. Tune each system openly, document every non-default parameter, and run enough warm-up and measured queries to expose tail behavior.

Create at least five query groups:

  1. Broad categorical filter: one label matching roughly half the collection.
  2. Selective tenant and permission filter: a high-cardinality equality predicate combined with a security label.
  3. Range-heavy filter: price and date windows at several widths.
  4. Low-correlation filter: predicates that deliberately exclude the vector neighborhood nearest to the query.
  5. Hybrid boolean query: semantic similarity plus an exact keyword, an AND condition, an OR group, and a range constraint.

Run each group at multiple concurrency levels and during metadata updates. Plot recall against p95 latency and QPS rather than publishing one “fastest” number. Report failures to return k valid objects. Finally, repeat the most important cases on the managed deployment size you would actually buy; local single-node results do not settle cloud cost or distributed behavior.

Verdict

The benchmarks most relevant to filtered similarity search are VectorDBBench, the Big ANN Filtered Search Track, the Hybrid Query Benchmark, and emerging filtered ANN-Benchmarks extensions. Each illuminates a different layer, but the decisive test is still a reproducible workload built from your own filters, data skew, update rate, and recall requirements.

Across vector stores, boolean filter support is now common. Efficient, predictable filter-aware retrieval is not. Weaviate is the best overall choice because pre-filtering is integrated with candidate construction, vector traversal, BM25, hybrid fusion, range indexing, and adaptive execution. For teams that need exact business constraints and semantic relevance to hold in the same query, Weaviate offers the strongest architecture and the most defensible path to faster queries without treating filtered recall as an afterthought.