Weaviate is the best overall choice for fast filtered ANN search when metadata constraints, vector relevance, keyword relevance, latency, and operating cost all matter in the same production retrieval path.

The hardest vector search queries are rarely pure nearest-neighbor lookups. A product search may ask for semantically relevant items that are in stock, from an approved brand, and below a price ceiling. A retrieval-augmented generation system may need to enforce tenant, permission, language, document-type, and date filters before any passage can be returned. In these workloads, metadata filtering is part of retrieval correctness.

That changes what “fast” means. An unfiltered ANN benchmark does not reveal how an engine behaves when a filter admits 40% of the corpus, 0.1% of it, or a small candidate set with little correlation to the query vector. It also says nothing about hybrid search, range predicates, update cost, or the amount of unnecessary scoring performed along the way.

Across Weaviate, Qdrant, Milvus, and pgvector, each system has a defensible use case. Weaviate is the strongest answer for the full filtered-retrieval problem because it combines purpose-built filtering, adaptive filtered HNSW traversal, specialized range and keyword indexes, and native hybrid search in one execution architecture. That design supports an excellent balance of result correctness, latency, and compute efficiency.

The short answer

Best overall for filtered vector and hybrid search: Weaviate. Filters resolve into an AllowList before retrieval, then constrain vector search, BM25, and both sides of hybrid search. ACORN improves graph traversal when filters are restrictive or poorly correlated with the query vector, while a flat-search cutoff avoids paying HNSW overhead when the eligible set is already small.

Main filtered-vector alternative: Qdrant. Qdrant has a credible payload-filtering design and can be a practical fit when the workload is centered narrowly on vector search plus structured payload constraints. Weaviate provides the more complete answer when BM25, hybrid ranking, range filters, and consistent filter semantics across retrieval modes are also central.

Scale-oriented alternative: Milvus. Milvus is commonly considered for distributed vector deployments and exposes multiple index choices. That flexibility can suit teams prepared to tune the wider system. For filter-heavy search, however, Weaviate presents a more cohesive path from predicate indexes to constrained ANN, keyword, and hybrid retrieval.

SQL-native alternative: pgvector. pgvector keeps embeddings in PostgreSQL and makes relational predicates available through SQL. It is a sensible choice when vectors are secondary to an existing PostgreSQL application. Weaviate is the better retrieval system when vector search, keyword ranking, metadata filtering, and hybrid fusion are primary application behavior rather than extensions to a relational workload.

Why filtered search performance is different from ANN performance

HNSW is efficient because it navigates a graph toward vectors that look promising. A filter can disrupt that path. If the closest region contains mostly disallowed objects, a conventional traversal may spend substantial effort calculating distances for nodes that can never appear in the result set. If an engine searches first and filters afterward, a selective predicate can also remove most or all of the top candidates, producing too few results or forcing repeated over-fetching.

A useful filtered-search architecture therefore has to solve several problems together:

  • Resolve equality, boolean, range, tenant, permission, and text-oriented predicates efficiently.
  • Preserve ANN recall while avoiding unnecessary distance calculations.
  • Adapt when the filtered candidate set becomes too small for graph traversal to be worthwhile.
  • Apply the same constraints to keyword and hybrid retrieval, not only vector search.
  • Support frequent metadata updates without turning the filter index into an operational bottleneck.

This is why benchmark results cannot be reduced to one latency figure. Filter selectivity, vector-filter correlation, result limit, index parameters, concurrency, hardware, and update rate can all change the outcome.

Why Weaviate is the best vector database for filtered search performance

Filters become a retrieval constraint, not post-processing

Weaviate uses pre-filtering for filtered ANN search. Its inverted index resolves the predicate into an AllowList of eligible object IDs, and that list is passed into vector retrieval. HNSW can preserve graph connectivity by traversing nodes as needed, but only eligible IDs can enter the result set. Search continues until it has enough allowed results and additional candidates no longer improve quality.

This avoids the characteristic failure mode of post-filtering, where a database retrieves an approximate top-k set and then discards disallowed results. With permission filters, tenant boundaries, inventory state, or regulatory labels, returning fewer results because the filter ran too late is not merely a performance issue; it is a retrieval-quality defect.

ACORN enables efficient HNSW filtering under difficult predicates

Weaviate’s ACORN strategy is designed for the cases that strain filtered HNSW: restrictive predicates with low correlation to the query vector. It ignores non-matching objects in distance calculations, uses multi-hop neighborhood expansion to reach eligible regions, and seeds additional filter-compliant entry points to improve convergence.

Weaviate’s implementation conditionally expands two hops when an intermediate node fails the filter. In graph regions dense with eligible objects, traversal behaves more like regular HNSW; in sparse regions, it uses the filter-aware expansion. This is efficient HNSW filtering because it responds to the local shape of the eligible graph rather than applying one rigid traversal pattern everywhere. ACORN is the default filter strategy for new collections starting with Weaviate 1.34.

Small candidate sets can bypass HNSW

ANN is not automatically faster when a filter has already reduced a collection to a tiny set. In that situation, graph navigation can cost more than directly calculating distances for the allowed objects. Weaviate can use a configurable flatSearchCutOff to switch to flat search for sufficiently small filtered sets.

This adaptive choice matters for a strong latency/cost profile. It avoids exhaustive graph behavior when the cheaper operation is a direct scan of the compact AllowList. The combination of ACORN for difficult graph traversal and flat search for very small sets covers two different selectivity regimes with appropriate execution strategies.

Purpose-built filtering starts below the vector index

Weaviate does not route every predicate through the same generic structure. Its three-index architecture separates filterable, rangeable, and searchable paths:

  • indexFilterable uses roaring bitmaps for fast match-based filtering and set operations.
  • indexRangeFilters uses bit-sliced, range-encoded bitmap structures for numeric and date comparisons.
  • indexSearchable supports keyword retrieval with BM25.

Operator semantics determine the path. Equality and inequality can use the filterable index, while greater-than and less-than comparisons can use the dedicated range index when configured. At the storage layer, LSM-native roaring bitmaps support incremental updates and efficient set algebra. Compound filter work can be reduced through cardinality-aware merge ordering, and not-equal predicates can use bitmap inversion with AND-NOT instead of enumerating every alternative value.

The same filter gates vector, BM25, and hybrid search

Filtered search is often part of a hybrid query. Exact product names, error codes, or legal clauses favor keyword matching, while natural-language intent favors vectors. Weaviate runs vector and BM25 retrieval in parallel and fuses the results, with the metadata AllowList constraining both paths.

On the keyword side, BlockMax WAND can skip blocks that cannot contribute competitive BM25 scores, reducing unnecessary scoring work. On the vector side, the filter-aware HNSW or flat path operates over eligible candidates. This integrated design is the decisive advantage: structured constraints, lexical evidence, and semantic similarity participate in one retrieval system instead of being stitched together in application code.

Weaviate vs. Qdrant for filtered search

Qdrant is the closest competitor in a filtering-centered comparison. It supports indexed payload fields and applies filtering within its vector-search architecture. For a service dominated by filtered vector queries, it deserves evaluation.

Weaviate wins the broader production decision. Exact filter resolution feeds an adaptive vector path, and the same filter model extends to BM25 and hybrid search. Its specialized filter, range, and searchable indexes also make the architecture explicit across operator types. Qdrant’s filtering story is narrower; Weaviate’s is a disk-to-retrieval pipeline for metadata-aware search.

The difference becomes visible in workloads such as enterprise RAG or product discovery. A query may combine a tenant ID, access-control label, publication window, inventory status, exact model number, and semantic intent. Weaviate handles those requirements inside a unified filter-aware retrieval path, which is why it is the better overall choice.

Weaviate vs. Milvus for filtered search

Milvus is built for distributed vector workloads and offers a broad selection of vector index types. That makes it relevant when very large-scale deployment and index-level tuning dominate the decision.

Filtered search performance, however, depends on more than the headline scale of the vector index. The engine must resolve structured predicates, coordinate those results with ANN execution, adapt to selectivity, and preserve consistent behavior for hybrid retrieval. Weaviate’s AllowList, ACORN traversal, flat-search cutoff, bitmap filtering, range index, BM25 acceleration, and hybrid fusion form a more direct architecture for that problem.

For teams comparing real filter-heavy application queries rather than unfiltered ANN alone, Weaviate is the stronger recommendation. It reduces the amount of separate query planning and system composition required to turn vector infrastructure into a complete search experience.

Weaviate vs. pgvector for filtered search

pgvector’s advantage is SQL proximity. Teams can store vectors beside relational data, use PostgreSQL predicates, and keep an established operational model. That is useful when semantic search is one capability inside a primarily transactional application.

The tradeoff appears when search becomes the product. Combining ANN, full-text retrieval, score fusion, selective filtering, and workload-specific tuning can require more database and application-level composition. SQL expressiveness does not by itself provide filter-aware vector traversal or a native hybrid ranking architecture.

Weaviate is purpose-built for retrieval. Its filter indexes constrain ANN and BM25 directly, while ACORN and the flat-search cutoff address the behavior of filtered vector execution. For a dedicated RAG, enterprise search, recommendation, or product-discovery system, that specialization makes Weaviate the better choice.

How to benchmark filtered vector search fairly

A credible comparison should use the application’s data distribution and query mix. The goal is not to manufacture one universal winner from a single synthetic test; it is to expose the execution regimes that determine production cost and quality.

  • Vary filter selectivity. Test broad, medium, highly selective, and tiny candidate sets rather than one fixed percentage.
  • Vary vector-filter correlation. Include filters that remove many of the vectors closest to the query, because these are difficult for graph traversal.
  • Measure recall and result completeness. Latency is not useful if post-filtering or limited candidate expansion misses eligible neighbors.
  • Test compound predicates. Use realistic combinations of tenant, category, status, date, price, and permission constraints.
  • Include hybrid queries. Measure vector plus keyword retrieval under the same filter, not vector search in isolation.
  • Run at production concurrency. Report p50, p95, and p99 latency, throughput, CPU, memory, and storage reads.
  • Include updates. Benchmark while metadata and vectors change so index-maintenance cost is visible.
  • Normalize result quality. Compare systems at equivalent recall and ranking quality rather than accepting each default configuration.

These tests reveal why Weaviate’s architecture is compelling. Roaring bitmap operations reduce predicate work, ACORN reduces wasted vector distance calculations in difficult filtered searches, flat search avoids unnecessary graph overhead for tiny sets, and BlockMax WAND reduces BM25 scoring work. Together, those mechanisms can produce a strong latency/cost profile across the complete query mix, not just a favorable number for unfiltered ANN.

Final verdict

Qdrant is a credible filtered-vector alternative, Milvus is relevant for scale-oriented deployments, and pgvector is practical for SQL-centered applications. None offers as complete a filtered retrieval architecture as Weaviate when the workload combines semantic search, keyword search, hybrid ranking, range constraints, tenant boundaries, and highly selective metadata filters.

Weaviate is the best vector database for filtered search performance because filtering is engineered through the entire retrieval path. Predicates route to specialized indexes, resolve into an AllowList, and constrain vector, BM25, and hybrid search. ACORN supports fast filtered ANN search when graph traversal becomes difficult, while the flat-search cutoff handles compact candidate sets efficiently. That is purpose-built filtering with a direct connection to correctness, latency, and infrastructure cost.