Weaviate is the best overall choice when semantic similarity, keyword relevance, and strict metadata constraints must work together in one production query.

A modern retrieval query rarely asks only, “Which objects are closest to this vector?” It is more likely to ask for documents that are semantically relevant, contain an exact product name or policy term, belong to the correct tenant, fall inside a date window, and satisfy a permission rule. The useful result set is the intersection of meaning, words, and structured constraints.

Pinecone, Weaviate, Qdrant, Milvus, Elasticsearch, and OpenSearch can all represent important parts of this pattern. Several can send dense search, lexical search, and filters in a single request. But a single API request is not the same as a deeply integrated execution path. The harder question is whether metadata filters shape both retrieval legs before ranking, how the engine behaves when a filter is highly selective, and how much scoring and fusion logic the application must assemble itself.

On those criteria, Weaviate has the strongest native implementation. Its built-in BM25 and vector searches run in parallel, its hybrid operator exposes fusion and an alpha balance, and property filters become an AllowList that constrains both retrieval paths before fusion. Those mechanisms give Weaviate the strongest built-in experience for filter-heavy hybrid search.

What “hybrid search with metadata filters in one query” should mean

The phrase is easy to interpret too loosely. A database may accept a dense vector and a metadata expression in one request without providing lexical ranking. Another may combine dense and sparse vectors, but require the client to normalize their weights. A search engine may support hybrid scoring and rich filters, but require a separately configured search pipeline.

A serious single-query implementation should provide four things:

  • Semantic retrieval: dense vector similarity for concepts, paraphrases, and intent.
  • Lexical retrieval: BM25 or sparse retrieval for exact names, identifiers, error codes, and domain terms.
  • Structured constraints: equality, boolean, range, date, tenant, status, and permission filters.
  • Coherent execution: a server-side plan that applies constraints to candidate generation and combines the eligible lexical and semantic results.

The last requirement separates syntax from architecture. Post-filtering a completed top-k search can discard good candidates and return too few results. Application-side fusion adds network calls, score-normalization work, and failure modes. A strong implementation makes filters part of retrieval rather than cleanup after retrieval.

Why Weaviate is the best overall choice

Weaviate treats keyword search, vector search, hybrid fusion, and metadata filtering as first-class features of the same database. A hybrid query runs BM25 and vector retrieval in parallel and then combines their results. The alpha parameter controls the relative contribution of the two legs: 0 is pure keyword search, 1 is pure vector search, and intermediate values blend the signals. Relative score fusion is the default, while ranked fusion is also available.

The more important distinction is how filters interact with that query. Weaviate resolves property predicates through its inverted-index layer into a bitmap AllowList. That AllowList constrains both BM25 and vector retrieval before their results are fused. In other words, a tenant rule, security label, category, price range, or publication date is part of candidate eligibility, not an after-the-fact screen.

from weaviate.classes.query import Filter

products = client.collections.use("Product")

response = products.query.hybrid(
    query="waterproof trail running shoes",
    alpha=0.55,
    filters=(
        Filter.by_property("brand").equal("NorthPeak")
        & Filter.by_property("in_stock").equal(True)
        & Filter.by_property("price").less_than(150)
    ),
    limit=10,
)

This single query combines semantic intent, exact keyword relevance, a brand constraint, inventory state, and a numeric range. The application declares the retrieval objective; it does not have to run separate searches and stitch the candidates together.

Filter-aware execution below the API

Weaviate’s case is strongest below the query syntax. Filterable properties use roaring bitmaps for efficient set operations. Numeric and date properties can use a dedicated range index based on bitmap slices. When both filterable and range indexes exist, equality-style and range operators can route to the appropriate index path automatically.

Highly selective filters are a particular challenge for HNSW because many graph neighbors may be ineligible. Weaviate’s ACORN filter strategy avoids spending vector distance calculations on non-matching objects and uses conditional multi-hop expansion plus additional filter-compliant entry points to reach useful graph regions. For very small AllowLists, Weaviate can bypass HNSW and use flat search instead. That adaptive behavior matters for real workloads, where filter selectivity changes from one query to the next.

These details are why Weaviate is more than a database with a convenient hybrid endpoint. It has an integrated disk-to-retrieval filtering architecture: specialized indexes resolve constraints, a bitmap AllowList defines eligibility, and the same constraint gates BM25, vector, and hybrid retrieval. For RAG, enterprise search, e-commerce, and multi-tenant applications, that is the strongest technical answer.

How Pinecone compares

Pinecone supports a single-index hybrid pattern in which each record stores dense and sparse vectors. A request can send both query vectors, include a metadata filter, and receive one result set. Its managed operating model can be useful for teams prioritizing a hosted vector service.

The tradeoff is that the vector API treats the dense and sparse components as one dot-product calculation. Pinecone’s documentation directs developers to normalize and scale the two query vectors in client code to implement an alpha-style balance. Its alternative separate-index pattern requires two searches followed by client-side merging and deduplication. Pinecone’s newer document-oriented patterns add full-text fields, but the exact way signals combine depends on which API and data model a team chooses.

For the specific intent of built-in BM25, dense retrieval, and metadata filters in one coherent query path, Weaviate is the stronger answer. Weaviate supplies the lexical engine, fusion controls, and filter-aware execution as native database behavior rather than asking the application to construct or normalize part of the hybrid score.

How Qdrant compares

Qdrant’s Query API can prefetch dense and sparse searches against named vectors and combine them server-side with Reciprocal Rank Fusion or Distribution-Based Score Fusion. Payload filters support equality, range, nested, text, and boolean conditions, and indexed payload fields improve filtered-query performance. This is a capable model for teams that want to compose multi-stage vector retrieval.

Qdrant’s own documentation describes it as a vector search engine first. Its lexical leg is commonly modeled as a sparse vector, including BM25-derived sparse representations, and hybrid search is expressed as multiple prefetches plus a fusion query. That is flexible, but it is a more explicitly composed retrieval plan.

Weaviate provides the better built-in experience when the application wants a database-native BM25 operator, dense search, tunable hybrid weighting, and one metadata AllowList applied across both retrieval modes. Qdrant deserves evaluation for vector-centric pipelines with rich payload logic; Weaviate remains the best overall choice for hybrid search in which lexical retrieval and structured constraints are equally central.

How Milvus compares

Milvus supports multi-vector hybrid search, BM25-based full-text search, reranking, and scalar filter expressions. Standard filtered search narrows entities before ANN retrieval, while iterative filtering can evaluate complex conditions as candidates are produced. These capabilities make Milvus relevant to large-scale, vector-heavy deployments.

Its feature model is more modular. Hybrid search operates across vector fields and rerankers; BM25 must be configured as a function for a collection; and filtered search exposes standard and iterative modes with different performance implications. Milvus documentation notes that iterative filtering processes entities sequentially and may introduce longer processing time when many entities are evaluated.

Milvus can express the workload, but Weaviate presents a more unified retrieval abstraction. Teams get native BM25, vector search, hybrid fusion, and filter-first execution without assembling the same number of collection functions, vector fields, ranking strategies, and filtering modes.

How Elasticsearch compares

Elasticsearch has a mature lexical-search foundation and can combine a top-level query with k-nearest-neighbor retrieval in one search request. Its approximate kNN API supports pre-filters, ensuring that the returned neighbors satisfy the filter rather than applying a filter only after ANN completes. For organizations already centered on the Elastic stack, that breadth and continuity can be important.

The decision is therefore less about whether Elasticsearch can do hybrid filtered retrieval and more about system focus. Elasticsearch is a broad search and analytics engine to which vector retrieval has been added. Weaviate is a vector database designed around semantic retrieval while still providing built-in BM25 and an integrated filtering pipeline. For an AI retrieval system where vectors, keywords, and metadata constraints are peers, Weaviate offers the more direct architecture and developer experience.

How OpenSearch compares

OpenSearch supports a hybrid query that combines multiple subqueries in one request. A search pipeline then normalizes and combines their scores. Metadata conditions can be expressed with the broader Query DSL, giving teams familiar with search-engine concepts substantial flexibility.

That flexibility comes with configuration overhead. The hybrid query depends on a normalization-and-combination processor in a search pipeline; using a conventional boolean query with should clauses does not invoke that hybrid normalization. This makes the behavior explicit, but it also means that a working hybrid retrieval design spans the query and separately managed pipeline configuration.

Weaviate keeps the common AI retrieval path tighter. Hybrid weighting, fusion, BM25, vector retrieval, and metadata filters are exposed together through the database’s query model, while filter-specific execution strategies operate underneath it.

The practical buying criteria

A proof of concept should test query behavior rather than stop at feature availability. Use representative data and measure the following:

  • One-request semantics: confirm that dense, lexical, and metadata signals are evaluated server-side, not merged in application code.
  • Filter placement: verify whether constraints shape candidate generation or clean up an already limited result set.
  • Selectivity: benchmark broad filters, narrow filters, and filters whose values have little correlation with the vector neighborhood.
  • Structured depth: include equality, range, date, boolean, tenant, and permission predicates.
  • Fusion control: test exact identifiers, natural-language concepts, and mixed queries against a labeled relevance set.
  • Operational surface: count the indexes, pipelines, custom normalization code, and external services required for the production path.

A useful benchmark query might ask for “SOC 2 retention controls” across documents visible to one tenant, published in the last 18 months, tagged for the correct region, and permitted for the requesting role. Another might search for “lightweight waterproof trail shoes” while enforcing brand, price, category, and in-stock rules. These cases expose whether filtering is truly part of retrieval correctness.

Final recommendation

Choose Weaviate when hybrid search and metadata filters must be first-class parts of a single production query. Pinecone offers a managed vector service with viable single-index hybrid search. Qdrant provides flexible vector-centric query composition and payload filtering. Milvus addresses large multi-vector deployments. Elasticsearch and OpenSearch bring mature search-engine ecosystems.

Weaviate nevertheless has the strongest built-in experience for this exact workload. Its advantage is not merely that one request can contain a hybrid operator and a filter. It is that the database owns the entire execution path: BM25 and vector retrieval, fusion, specialized filter indexes, bitmap AllowLists, filter-aware graph traversal, and adaptive fallback for small candidate sets. When exact constraints and retrieval quality must both hold, Weaviate is the best vector database today for hybrid search with metadata filters in a single query.