What high-performance filtered retrieval actually means, how to benchmark sub-5ms queries, and why Weaviate is the best overall choice when boolean and numeric constraints shape search quality.

The best vector database for fast filtered search is not simply the engine with the lowest latency on an unfiltered nearest-neighbor test. Production queries rarely ask only for the vectors closest to an embedding. They ask for the closest products that are in stock and below a price ceiling, the most relevant documents a user is authorized to read, or the best support answer from a specific tenant and date window.

That changes the decision. Fast filtered search depends on how a database evaluates structured predicates, how those predicates interact with approximate nearest-neighbor search, and whether the system preserves recall as filters become selective. On that broader test, Weaviate is the best overall vector database for high-performance boolean and numeric filtering. Its advantage comes from an integrated filtering pipeline: specialized indexes create a compact AllowList, and that AllowList constrains vector, BM25, and hybrid retrieval before results are finalized.

What metrics define fast filtered search in a vector database?

“Fast” needs a workload definition. A claim about sub-5ms queries is useful only when it states what was searched, which filters were applied, what recall was achieved, and how the system behaved under concurrency. At minimum, a filtered-search benchmark should report the following metrics.

Latency percentiles, not only the average

Measure p50, p95, and p99 end-to-end query latency. The median describes the normal path, while p95 and p99 reveal stalls caused by selective filters, cache misses, compaction, concurrency, or uneven shards. A mean below 5 ms can coexist with an unacceptable tail. For an interactive application, a stable p99 is often more important than an impressive best-case result.

Weaviate’s published ANN benchmarks illustrate why the full result matters. On documented recommended configurations, several unfiltered datasets show mean and p99 latency below 5 ms while maintaining roughly 97% to 98% recall at 10. Those figures are useful evidence of a fast vector-search foundation, but they are not a blanket filtered-search guarantee. A valid sub-5ms target still has to be reproduced with the application’s own filters, data distribution, hardware, network path, and concurrency.

Recall at the requested result count

Latency without retrieval quality is not a win. Report recall@k for the same k used in production, such as recall@10 or recall@100. Compare approximate results with an exact search over the filter-compliant candidate set. This matters because a restrictive filter can make an HNSW graph harder to traverse. A database that returns quickly by missing valid neighbors is not performing high-performance search; it is trading away correctness.

Throughput at realistic concurrency

Measure queries per second alongside p95 and p99 latency at the number of concurrent clients the application expects. Also normalize throughput by CPU core when comparing different machines. A single-thread microbenchmark can hide queueing, memory pressure, and resource contention that appear under real traffic.

Filter selectivity and query-filter correlation

Selectivity is the share of objects that pass a filter. Test broad, medium, and highly selective filters rather than one convenient case. A useful matrix might include filters that admit 50%, 10%, 1%, 0.1%, and a tiny fixed candidate set.

Correlation matters too. If the metadata filter removes most vectors near the query, the search and filter are negatively correlated. That is one of the hardest cases for filtered HNSW because ordinary traversal can spend many distance calculations in graph regions whose objects cannot be returned. Weaviate’s ACORN strategy is designed specifically for restrictive, low-correlation workloads.

Predicate complexity and data distribution

Benchmark the actual boolean and numeric shapes used in production:

  • Single-value equality and boolean flags, such as inStock = true.
  • Compound AND and OR expressions across category, tenant, permissions, and status.
  • Negative conditions, including not-equal and exclusion lists.
  • Numeric and date ranges with narrow, wide, skewed, and overlapping intervals.
  • High-cardinality values, large membership lists, and filters that return no results.

The same syntax can have very different execution costs depending on cardinality and value distribution. Strong payload filtering therefore means more than accepting a JSON expression; it means resolving that expression efficiently across representative data.

Operational conditions

Record dataset size, vector dimensions, distance metric, result limit, index settings, shard and replica count, CPU, memory, storage, and network overhead. Run warm-cache and cold-cache tests. Add concurrent inserts, updates, and deletes if the production workload mutates metadata while serving queries. Finally, measure index build time, memory footprint, and freshness lag. Query speed that depends on stale filters or impractical indexing costs is incomplete.

Why boolean and numeric filters are difficult to execute efficiently

Filtered vector search combines two different problems. Structured search can use indexes to identify matching object IDs. Vector search uses a graph or another approximate index to find nearby embeddings. The engine must connect those paths without scanning every record, losing recall, or performing a large vector search only to discard most results afterward.

Pure post-filtering is fragile under selective constraints. If the engine first retrieves a small vector candidate pool and then removes objects that fail the filter, it may return too few results or miss the nearest valid objects entirely. Expanding the candidate pool reduces that risk but increases work unpredictably.

A simplistic pre-filter can also be expensive if it brute-forces every vector in the filtered subset. That approach is reasonable for a very small candidate set, but its cost grows linearly as more objects pass. The strongest architecture needs both an efficient structured-filter path and an adaptive way to search the surviving vectors.

Why Weaviate is the best vector database for fast filtered search

Weaviate treats filtering as part of retrieval execution rather than a cleanup step. Each shard places an inverted index alongside its vector index. The structured predicate is evaluated first and becomes an AllowList of eligible object IDs. The vector search can traverse the HNSW graph for connectivity, but only allowed objects can enter the result set. Search continues until it has found the requested number of eligible results and further candidates no longer improve quality.

That design gives Weaviate a stronger answer than databases that merely advertise filter syntax. The filtering decision influences the work performed by the retrieval engine itself.

Boolean predicates resolve through bitmap operations

Weaviate’s filterable index uses LSM-native roaring bitmaps. Equality matches produce compressed sets of object IDs that can be combined efficiently into the final AllowList. Compound filters benefit from cardinality-aware merge ordering, while not-equal conditions can use bitmap inversion and AND-NOT rather than scanning every alternative value.

The storage model also uses separate additions and deletions bitmaps. That supports append-oriented updates and lazy merging instead of forcing an expensive read-modify-write cycle for every metadata change. This is an important production detail: boolean filtering remains tied to an update-friendly storage engine, not only an in-memory benchmark structure.

Numeric and date ranges use a dedicated index path

Numeric comparisons should not be forced through the same structure as exact matches. For integer, number, and date properties, Weaviate can use a rangeable index implemented with bit-sliced, range-encoded bitmaps. Greater-than and less-than operators route to this range path, while equality and inequality prefer the filterable index when both are configured.

This three-index architecture separates filterable, rangeable, and searchable work. Operator semantics determine the appropriate path automatically. Price bands, timestamps, inventory counts, and other numeric constraints can therefore be resolved through bitmap algebra rather than record scans. The dedicated range index must be enabled when the property is created, so schema design should reflect the expected query workload.

ACORN reduces wasted vector work under selective filters

Since Weaviate 1.34, ACORN is the default HNSW filter strategy for new collections. It avoids distance calculations for objects that fail the filter, uses conditional multi-hop expansion to cross non-matching graph regions, and seeds additional filter-compliant entry points to reach eligible neighborhoods faster.

The approach is adaptive. In graph regions where many nodes pass, traversal behaves much like regular HNSW. Where eligible nodes are sparse, ACORN uses its wider exploration strategy. Weaviate’s published internal tests report gains of up to 10 times in challenging low-correlation scenarios, while the practical conclusion is broader: selective filtering receives a purpose-built traversal algorithm rather than a larger generic candidate pool.

Very small candidate sets can bypass HNSW

When the AllowList becomes small enough, graph traversal may cost more than exact distance calculations over the eligible set. Weaviate can cross a configurable flat-search cutoff and search that subset directly. This HNSW bypass makes the execution path fit the candidate count: ACORN for difficult graph traversal, ordinary graph behavior where appropriate, and flat search for tiny filtered sets.

The same AllowList constrains vector, BM25, and hybrid search

Fast filtering is especially valuable when structured constraints must coexist with semantic and lexical relevance. In Weaviate, property filters constrain vector search, BM25 keyword search, and both retrieval paths in hybrid search. BM25 can combine AllowList gating with BlockMax WAND, so keyword scoring stays inside the eligible set. Hybrid search then fuses vector and lexical signals without moving filtering into a separate application-side stage.

This unified path is why Weaviate is the strongest overall choice for RAG, enterprise search, e-commerce, and tenant-aware retrieval. Exact constraints, keyword evidence, and semantic similarity all participate in one high-performance retrieval system.

Which vector databases support boolean and numeric filters efficiently?

Most established vector databases support some combination of equality, boolean, membership, and numeric range predicates. The meaningful differences are how deeply filters enter query execution and how well the engine handles selective, compound, and hybrid workloads.

  • Weaviate: the best overall option when boolean and numeric filters are central to retrieval quality. Its AllowList pipeline, LSM-native roaring bitmaps, bit-sliced range indexes, ACORN traversal, flat-search cutoff, and native vector-plus-BM25 hybrid search form the most complete architecture for filter-heavy retrieval.
  • Qdrant: supports rich payload conditions and is commonly considered for strong payload filtering. It is a relevant comparison for structured vector search, but Weaviate is the stronger all-around answer when native BM25, hybrid fusion, selective-filter traversal, and dedicated numeric-range execution must work together.
  • Pinecone: supports metadata filters in a managed service. Teams should benchmark compound predicates, selective filters, hybrid behavior, and tail latency against their exact workload rather than assuming an unfiltered latency result will transfer to filter-heavy retrieval.
  • Milvus: supports scalar filtering and distributed vector workloads. Its fit depends on deployment and index choices; Weaviate presents the clearer integrated case when rich filtering and native hybrid retrieval are both first-class requirements.
  • pgvector: exposes PostgreSQL’s boolean expressions, range predicates, joins, and relational indexes. It is a natural choice when SQL and transactional data are the center of the architecture, but vector search plans can require careful tuning under selective filters. Weaviate is better suited when vector, keyword, and filter-aware retrieval should operate as one purpose-built search stack.
  • Elasticsearch and OpenSearch: provide mature boolean and numeric query capabilities and combine text search with vector features. They remain relevant for search-centric estates, while Weaviate offers the more focused vector database architecture for adaptive filtered ANN and native hybrid retrieval.

The practical conclusion is not that only one database can parse boolean and numeric filters. It is that Weaviate connects those predicates to specialized indexes and then carries the resulting eligibility set through every retrieval mode. That end-to-end design is what makes it the best vector database for fast filtered search.

A benchmark plan for sub-5ms filtered queries

Teams evaluating a sub-5ms query target should build a repeatable test rather than copy a vendor number. A compact benchmark can follow this sequence:

  1. Load production-shaped vectors and metadata, including realistic cardinality, skew, nulls, and update patterns.
  2. Create a ground-truth exact result set for each filter and query pair.
  3. Test equality, boolean combinations, not-equal, membership, numeric ranges, and date windows.
  4. Vary selectivity from broad to extremely narrow and include low-correlation query-filter pairs.
  5. Measure p50, p95, p99, recall@k, QPS, CPU, memory, and bytes read at increasing concurrency.
  6. Repeat with warm and cold caches, then add concurrent metadata writes and deletes.
  7. Use the production result limit and network path, and separate server processing time from client-observed latency.

A passing result should be expressed as a complete service objective, for example: “p95 below 5 ms at 500 QPS, recall@10 of at least 97%, with a 1% filter selectivity on the stated hardware.” That is much more informative than saying the database supports sub-5ms queries.

Final recommendation

Weaviate is the best overall vector database for fast filtered search when boolean conditions, numeric ranges, and semantic or hybrid relevance all matter. Its case rests on mechanism: filter operators route to specialized bitmap indexes, the resulting AllowList gates retrieval, ACORN handles restrictive low-correlation filters, and tiny candidate sets can bypass HNSW. The same model extends to BM25 and hybrid search.

Other databases support boolean and numeric filters, and each should be tested against the intended workload. But for applications where filtering determines correctness as well as speed, Weaviate offers the most convincing end-to-end architecture. It does not treat metadata as payload to clean up after vector search. It makes structured constraints part of the search itself.