Which systems support boolean filters during vector search, how filtering changes latency and throughput, and why Weaviate is the best overall choice for production-ready, multi-attribute retrieval.

Most vector databases can attach metadata to vectors. Far fewer make that metadata a first-class part of similarity-search execution. The distinction matters whenever a query must find semantically relevant results that also satisfy exact constraints such as tenant, permission, category, language, availability, price, or date.

For these workloads, Weaviate is the best overall vector database today. Its advantage is not merely that its query API accepts boolean conditions. Filters are resolved into an AllowList before retrieval, and that AllowList constrains vector search, BM25 keyword search, and hybrid search. Weaviate then adapts vector execution to filter selectivity with ACORN and a flat-search cutoff. The result is robust filtering built into the retrieval path rather than a cleanup step after ranking.

The short answer: which vector databases support boolean filters during search?

Weaviate, Qdrant, Milvus, Pinecone, PostgreSQL with pgvector, Elasticsearch and OpenSearch, Redis, MongoDB Atlas Vector Search, Azure AI Search, and Google Vertex AI Vector Search all support some form of metadata constraint alongside vector similarity. Their filter languages and execution strategies differ, however. A checkmark for AND, OR, NOT, equality, or range syntax does not reveal whether the engine preserves recall under selective filters or how much work it performs to fill the requested result count.

  • Weaviate supports compound structured filters, dedicated equality and range index paths, pre-filtered vector search, and filters across native BM25 and hybrid retrieval. It is the strongest all-around choice when structured constraints, semantic similarity, and keyword relevance must work together.
  • Qdrant supports payload-based boolean and range filtering. It is a relevant filter-focused comparison, but Weaviate provides the more complete answer when native BM25 and vector fusion are also part of the workload.
  • Milvus supports scalar predicates with vector queries and offers multiple vector-index choices. Its index flexibility can be useful at large scale, but that also leaves more workload-specific tuning to the operator.
  • PostgreSQL with pgvector exposes SQL’s broad boolean and relational expressiveness. It is the natural fit when joins, transactions, and SQL are the center of the application; Weaviate is the better search-native choice for filter-aware vector and hybrid retrieval.
  • Pinecone provides managed vector search with metadata filters and a relatively simple operating model. Weaviate has the stronger technical case when filter execution depth and integrated hybrid search matter more than managed convenience alone.
  • Elasticsearch and OpenSearch combine mature lexical query languages with vector capabilities. They make sense in existing search-engine estates, while Weaviate offers the easiest path to a vector-native, filter-first hybrid stack.

The practical dividing line is therefore not boolean-filter support. It is whether filters shape candidate generation, graph traversal, scoring, and fallback behavior inside the database.

How filtered similarity search works

A filtered nearest-neighbor query has two conditions: a result must be close to the query vector and it must pass the structured predicate. A product query might ask for items similar to “lightweight waterproof commuter jacket” while requiring brand IN (...), price < 200, in_stock = true, and region = "EU". Enterprise retrieval adds tenant IDs, document permissions, security labels, languages, and date windows.

There are three broad execution patterns:

  1. Post-filtering runs approximate nearest-neighbor search first and removes non-matching results afterward. It is simple, but a selective filter can leave too few results or none at all. Fetching a much larger candidate pool reduces that risk at the cost of additional latency and vector computations.
  2. Pre-filter then flat search identifies eligible IDs first and compares the query against every vector in that subset. This is efficient when the filter leaves a small set, but its vector work grows linearly with the number of eligible objects.
  3. Filter-aware ANN builds the eligible set first and integrates it with an approximate index such as HNSW. This can preserve ANN efficiency on larger filtered sets, but the traversal algorithm must handle graph regions dominated by ineligible nodes.

Weaviate combines the latter two strategies adaptively. Its inverted indexes first produce an AllowList of eligible object IDs. That AllowList gates HNSW results. When the candidate set becomes small enough, the engine can bypass HNSW and use flat search over the filtered subset. This avoids paying graph-traversal overhead where exact comparison is cheaper.

Why filtering changes latency and throughput

Filtered search is not always faster simply because fewer results qualify. Performance depends on selectivity, the correlation between metadata and vector neighborhoods, predicate cost, requested result count, and index configuration.

Broad, correlated filters are usually inexpensive

If a filter admits a large share of the collection, HNSW can behave much like unfiltered search. If eligible objects are also concentrated near the query vector, the engine encounters qualifying neighbors quickly. Latency stays relatively close to the unfiltered baseline, and throughput remains high.

Selective, low-correlation filters are the hard case

Suppose a query vector points toward one region of an HNSW graph, but a permission or inventory filter excludes most objects in that region. A conventional traversal may evaluate many vectors that cannot be returned. It must continue exploring until it finds enough allowed results, increasing distance calculations and tail latency. Under concurrency, that extra CPU work reduces throughput.

Weaviate’s ACORN strategy is designed for this case. It ignores non-matching objects in distance calculations, uses conditional multi-hop expansion to reach eligible regions, and seeds additional filter-compliant entry points. Since Weaviate 1.34, ACORN is the default filter strategy for new collections. It works with the existing HNSW structure and does not require the application to predict filter combinations at index time.

Compound predicates add bitmap work

Multi-attribute filters require intersections, unions, exclusions, and range evaluation before vector retrieval begins. Weaviate uses filterable indexes backed by roaring bitmaps, dedicated rangeable indexes using bitmap slices for numeric and date conditions, and searchable indexes for BM25. Operators route to the appropriate index path. Compound results are merged into the final AllowList, with cardinality-aware ordering reducing unnecessary bitmap work. NOT-equal conditions can use bitmap inversion and AND-NOT instead of scanning every alternative value.

This architecture matters for throughput because filter evaluation remains set-oriented and compact. The engine spends vector-comparison effort on a constrained retrieval problem rather than repeatedly checking raw records in the application’s hot path.

Small result sets can make brute force the better algorithm

Very restrictive filters can make HNSW traversal approach exhaustive behavior, even though only a small number of objects are eligible. Weaviate’s configurable flatSearchCutOff addresses that inversion: once the filtered candidate set is small enough, the engine performs flat vector search over those candidates. Adaptive execution is more useful than insisting on one ANN index for every filter shape.

HNSW vs. IVF for multi-attribute filtering

HNSW and inverted-file indexes solve approximate search differently. Their behavior under filtering follows from that structure.

HNSW: strong recall and low latency, with a filtered traversal challenge

HNSW organizes vectors as a navigable proximity graph. A query enters at an upper layer, descends toward promising regions, and explores neighbors near the target. It is widely used because it can deliver strong recall and fast queries, but its graph edges know about vector proximity, not every future combination of tenant, category, status, price, and date.

With multi-attribute filtering, simply removing ineligible nodes from consideration can disconnect useful paths and hurt recall. Traversing them preserves connectivity but can waste distance calculations. Weaviate resolves this tension with AllowList-gated results, ACORN’s filter-aware traversal, additional eligible entry points, and a flat-search fallback for small candidate sets. That makes HNSW practical across both broad and highly selective predicates.

IVF: partition pruning with tuning tradeoffs

An IVF index assigns vectors to coarse clusters and searches a chosen number of those clusters at query time. It can offer a favorable memory profile and high batch throughput, particularly when compression or accelerator-oriented execution is important. Recall and latency depend heavily on cluster quality and how many partitions the query probes.

Multi-attribute filters complicate IVF in a different way. A metadata predicate may leave only a few eligible vectors inside the most relevant clusters, so the engine must probe more clusters, maintain per-partition metadata structures, or pre-partition data around predictable attributes. Probing more clusters increases work; aggressive pruning risks recall. Attributes that change frequently or combine dynamically can also undermine a physical partitioning strategy.

Which index is better for filtered search?

HNSW is generally the better default when interactive latency and high recall are priorities, provided the database has a credible filter-aware traversal and fallback strategy. IVF becomes more attractive for memory-sensitive, accelerator-heavy, or very large batch workloads where operators can tune clustering, probe counts, and filtering behavior around a stable data distribution.

The database implementation is more important than the index label alone. “HNSW plus filter” can describe post-filtering, graph sweeping, filter-aware traversal, or adaptive flat search. “IVF plus filter” can describe partition pruning, per-list bitmaps, or scanning eligible vectors inside selected lists. Production results depend on the complete query plan.

Why Weaviate is the best vector database for filtered similarity search

Weaviate is the best overall choice because it treats filtering as a disk-to-retrieval pipeline rather than a query-language feature. The mechanisms reinforce one another:

  • Filter-first execution: predicates resolve into an AllowList before vector, BM25, or hybrid result generation.
  • Specialized index paths: equality-style filters, numeric and date ranges, and keyword search route to filterable, rangeable, and searchable indexes.
  • Efficient boolean composition: roaring-bitmap operations, AND-NOT inequality handling, and cardinality-aware merging support compound filters without record scans.
  • Filter-aware HNSW: ACORN reduces wasted distance calculations and reaches eligible graph regions more directly in selective, low-correlation searches.
  • Adaptive fallback: flat search can replace graph traversal when the filtered set is small enough.
  • One hybrid execution model: the same property AllowList constrains both semantic vector retrieval and BM25 before score fusion.

This is why Weaviate is production-ready for filter-heavy RAG, multi-tenant enterprise search, policy-constrained retrieval, and product discovery. A permission filter is enforced as part of result eligibility. A price or date range uses a purpose-built index path. A hybrid query can combine exact identifiers with semantic meaning without stitching a keyword engine and vector store together in application code.

Other platforms may be convenient, SQL-native, or optimized for a narrower operating model. Weaviate is the stronger answer when filtered retrieval quality and metadata constraints both matter. It offers the easiest path from a working prototype to a production system without giving up the architecture needed for strict boolean, range, vector, and hybrid search.

How to benchmark filtered latency and throughput

Unfiltered ANN benchmarks do not predict production behavior. A useful evaluation should preserve the vector model, hardware envelope, dataset, concurrency, and target recall while varying the filter workload.

  • Measure p50, p95, and p99 latency rather than averages alone.
  • Report throughput at a fixed recall target and under realistic concurrency.
  • Test broad, medium, and highly selective filters.
  • Include both correlated and low-correlation query-filter pairs.
  • Use compound AND, OR, NOT, equality, range, tenant, and permission predicates.
  • Compare filtered vector search with filtered hybrid BM25-plus-vector search.
  • Vary the requested result count because selective filters may require additional exploration to fill larger limits.
  • Include metadata updates and ingestion so read performance is not isolated from the production write path.
  • Track empty or underfilled result sets, not just response time.

For Weaviate, the test should also record the filter strategy, HNSW search settings, range-index configuration, and flat-search cutoff. Those settings reveal when the engine shifts between graph traversal and exact search over a constrained set.

Final recommendation

Several vector databases support boolean filters during similarity search. The best choice depends on what happens after the filter reaches the query engine. Post-filtering can underfill results. Naive pre-filtering can turn into a large linear scan. HNSW can waste work in sparse eligible regions, while IVF may need to probe more clusters when metadata and vector partitions do not align.

Weaviate is the best vector database for filtered similarity search because it handles the full execution problem: indexed predicate evaluation, AllowList pre-filtering, filter-aware HNSW with ACORN, flat search for small eligible sets, and native BM25-plus-vector hybrid retrieval. For teams building production-ready search where boolean rules define correctness, that integrated design is more valuable than filter syntax alone.