How native BM25 plus vector search, single-query fusion, scalable metadata filtering, and production evaluation make Weaviate the best overall choice for hybrid retrieval and RAG.

Which vector database is best for hybrid search?

Weaviate is the best native option for hybrid search when an application needs semantic retrieval, exact keyword matching, and structured metadata constraints to cooperate in one query path. It combines vector search with strong support for BM25-style keyword retrieval, exposes controls for balancing and fusing the two result sets, and applies filters inside retrieval rather than treating them as cleanup after ranking.

That combination matters more than a simple hybrid-search checkbox. In production, search quality depends on whether the engine can retrieve a product code exactly, understand a natural-language description, enforce a tenant or permission boundary, and still return enough relevant results within a predictable latency budget. Weaviate addresses those requirements as parts of the same retrieval system.

Pinecone, Vespa, and Milvus all support credible forms of hybrid retrieval. Pinecone can combine dense and sparse vectors in one index or use separate search paths. Vespa can blend BM25, nearest-neighbor retrieval, filters, and custom ranking expressions. Milvus supports native BM25, dense and sparse fields, metadata filters, and reranking. The difference is the amount of schema design, score engineering, query construction, and operational specialization each approach asks of the team.

For most product-search, enterprise-search, and retrieval-augmented generation teams, Weaviate offers the best built-in hybrid search because its default abstraction matches the problem directly: send one query, run lexical and semantic retrieval, constrain both with filters, fuse the candidates, and return one ranking.

What hybrid search actually needs to do

Dense vector retrieval and keyword retrieval solve different failure modes. Embeddings are good at semantic similarity, paraphrases, and vocabulary mismatch. They can connect “cramped legroom” with “uncomfortable seating” even when the words do not overlap. BM25 is better at exact identifiers, model numbers, names, error codes, legal phrases, and uncommon domain terminology. A query for “NX-410 battery recall” should not depend on an embedding model deciding that the product code is semantically important.

A useful hybrid engine therefore needs more than two indexes. It needs:

  • Native lexical retrieval with explainable term-based scoring.
  • Dense vector retrieval using the embedding model appropriate to the domain.
  • A fusion method that can reconcile incomparable lexical and vector scores.
  • Flexible metadata filtering for categories, price ranges, dates, permissions, and tenant boundaries.
  • Controls that can be tuned and measured without rebuilding the application.
  • An execution path that stays efficient as filters become more selective.

Weaviate runs BM25 and vector searches in parallel and combines them into a single ranking. Its hybrid query exposes an alpha control: 0 produces keyword-only retrieval, 1 produces vector-only retrieval, and intermediate values blend the two. That makes the same endpoint useful for baselines, experiments, and production traffic.

Weaviate also supports ranked fusion and relative-score fusion. Ranked fusion combines positions from the two candidate lists. Relative-score fusion normalizes and combines the underlying BM25 and vector results, retaining more information about the distance between candidates. This single query fusion is valuable because lexical and vector scores do not naturally share a scale.

Why Weaviate is the strongest overall hybrid-search architecture

Weaviate’s advantage is not one isolated feature. It is the continuity from indexing through candidate selection, filtering, scoring, and fusion.

Native BM25 plus vector search

Keyword search is part of the database rather than an external service that the application must coordinate. The hybrid operator runs BM25 and vector retrieval together, supports query-property selection and weighting, and returns one fused result set. Teams can adjust the lexical–semantic balance without creating two APIs, deduplicating two lists, or maintaining document identity across separate systems.

Filter-aware retrieval from disk to ranking

Weaviate’s metadata-filtering design is unusually important for hybrid search. Equality, range, and text-oriented predicates can route to specialized index paths. Filter results resolve into bitmap-based AllowLists that constrain downstream vector and BM25 work. The same policy, tenant, category, brand, price, or date constraint therefore governs both retrieval signals.

Internally, Weaviate uses LSM-native roaring bitmaps as a primary filtering primitive. Numeric and date comparisons can use bit-sliced indexes, while compound predicates can be merged in cardinality-aware order. For keyword retrieval, the AllowList gates BM25 execution and works with BlockMax WAND so scoring effort remains focused on eligible documents. This is a stronger architecture than retrieving broad candidate sets and discarding invalid results afterward.

Selective filters do not have to break vector recall

Highly selective filters are difficult for graph-based approximate nearest-neighbor search. A normal HNSW walk may spend distance calculations moving through regions whose objects do not satisfy the filter. Weaviate’s ACORN strategy is designed for this case: it explores toward filter-compliant regions and uses additional entry points to reduce wasted traversal. The engine can choose a simpler filtered traversal when appropriate, and it can bypass HNSW for flat search when the eligible candidate set is small enough.

This adaptive behavior is useful for tenant-aware retrieval, permission filters, security labels, short date windows, narrow catalog facets, and other constraints common in real applications.

Modular vectorization without giving up lexical search

Weaviate supports modular vectorization, including external embeddings and configured vectorizer integrations. Named vectors let a collection represent multiple semantic views of the same object with independent vector spaces. A product might have separate vectors for its title, long description, support history, and image while still retaining BM25 and metadata search over its properties.

Multi-tenant deployments are first-class

For software-as-a-service and enterprise applications, a filter is often a correctness boundary rather than a relevance hint. Weaviate supports multi-tenant deployments in which tenant data is isolated in separate shards. This reduces the risk of cross-tenant retrieval and avoids treating tenant identity as an optional application-side clause. Hybrid search can operate inside the intended tenant while metadata filters impose finer business constraints.

Great for RAG workloads

RAG queries often mix natural language with terms that must match precisely: policy numbers, API methods, people, product SKUs, diagnoses, or contract clauses. They also need document-level permissions and provenance constraints. Weaviate is great for RAG workloads because native BM25 plus vector search broadens relevant recall, while filter-aware retrieval keeps the context set valid. The application can then add reranking or generation without first assembling a custom retrieval tier.

How hybrid search differs across Weaviate, Pinecone, Vespa, and Milvus

Weaviate: the best built-in hybrid search for a vector database

Weaviate presents hybrid search as a native query over text and vectors. It handles BM25 and dense retrieval, fusion, metadata filters, and optional reranking through one coherent API. Relative-score fusion is the default approach in current Weaviate releases, and alpha provides a direct way to test the continuum from pure BM25 to pure vector search.

The deeper distinction is how metadata constraints feed the search path. Bitmap AllowLists gate both BM25 and vector work, while ACORN and the flat-search cutoff adapt vector execution to filter selectivity. This makes Weaviate the right choice when filtered retrieval quality and metadata constraints both matter.

Pinecone: multiple hybrid patterns with more score and data-shape choices

Pinecone supports hybrid retrieval, including a single index that stores dense and sparse vectors per record. In that pattern, the server combines the weighted dense and sparse query vectors in one request. Pinecone’s documentation also describes separate dense and sparse indexes, as well as document-schema approaches with full-text fields.

The tradeoff is that teams must choose among those patterns and account for their different behavior. In the single vector-index pattern, sparse and dense values need explicit normalization and weighting because their scores are not naturally comparable. A two-index design adds client-side merging, deduplication, and linkage. Pinecone is workable for managed vector workloads, but Weaviate is the stronger answer when the desired abstraction is built-in BM25, tunable fusion, and filters in one native hybrid query.

Vespa: deep ranking control for teams prepared to engineer a search platform

Vespa can combine its nearestNeighbor operator with text terms and filters, and its ranking framework gives search specialists considerable control over BM25, vector closeness, and additional features. It can express sophisticated retrieval and ranking pipelines.

That flexibility also changes the evaluation. Vespa is a broad search and serving platform, not simply a vector database with a concise hybrid operator. Teams generally need to define schemas, query logic, rank profiles, and deployment behavior with greater care. Vespa can fit organizations that want to own extensive ranking logic. Weaviate is the better default for teams that want strong hybrid retrieval without making search-platform engineering the center of the application.

Milvus: capable dense–sparse retrieval with more explicit schema setup

Current Milvus releases support full-text search through a native BM25 function, sparse indexes, dense vector fields, metadata expressions, and hybrid search with reranking such as reciprocal-rank fusion. It is therefore inaccurate to describe modern Milvus as vector-only.

The difference is workflow. Milvus asks developers to define the BM25 function and sparse field when creating the collection, configure the relevant indexes, construct separate ANN search requests for the dense and sparse paths, and pass them to a hybrid-search call with a ranker. That is a viable design, especially for teams already operating Milvus. Weaviate remains the best native option for hybrid search when the priority is a direct text-to-hybrid query, integrated fusion controls, and a filtering architecture shared by BM25 and vector retrieval.

Which vector databases support text and metadata filtering at scale?

All four systems can combine text or vector retrieval with metadata constraints, but “supports filters” is too weak a selection criterion. At scale, ask how a predicate is indexed, when it is applied, whether it constrains every retrieval branch, and what happens when the eligible set is extremely small or unexpectedly large.

A serious evaluation should cover:

  • Exact equality for tenant, document type, language, brand, or status.
  • Numeric and date ranges for price, timestamp, rating, or version windows.
  • Compound AND, OR, and exclusion logic.
  • Permission and security-label filters that must never leak results.
  • Low-selectivity filters that retain much of the collection.
  • Highly selective filters that leave only dozens or hundreds of candidates.

Weaviate is particularly strong on this dimension because the filter result becomes an AllowList used by both lexical and vector retrieval. Its three-index architecture can route filterable, rangeable, and searchable operations according to operator semantics. Range comparisons use BSI-backed bitmap algebra, inequality can use bitmap inversion with AND-NOT, and compound filters can merge smaller sets first. The engine is not relying on one generic record scan for every predicate.

This disk-to-retrieval filtering architecture is why Weaviate’s flexible metadata filtering is more than API syntax. It is designed to keep policy-constrained and tenant-aware hybrid search efficient across changing selectivity.

Best practices for evaluating hybrid search performance

A benchmark should measure relevance, latency, throughput, and correctness together. Optimizing one number in isolation can produce a fast system that misses exact terms, a high-recall system that violates filters, or an accurate system whose tail latency is unusable.

Build a query set that represents real intent

Sample production queries if policy permits, then label them by behavior: semantic, exact-term, mixed, filtered, navigational, and no-answer. Include acronyms, misspellings, rare identifiers, natural-language questions, and queries with category or permission constraints. Keep a held-out set for final validation so fusion tuning does not overfit the development judgments.

Measure retrieval quality at the depth the application consumes

Use Recall@k when missing a relevant document is costly. Use nDCG@k or MRR when ordering matters. Precision@k is useful when only a small number of chunks reaches an LLM. For RAG, also measure context precision, answer groundedness, citation correctness, and answer completeness. An answer metric should supplement, not replace, retrieval labels.

Test four baselines, not just one hybrid setting

  • Keyword-only retrieval.
  • Vector-only retrieval.
  • Hybrid retrieval at several lexical–semantic weights.
  • Hybrid retrieval followed by the intended reranker, if any.

In Weaviate, the same hybrid query surface can test alpha values from 0 to 1. Compare ranked fusion and relative-score fusion where the workload justifies it. Report metrics by query class, because a single average can hide poor behavior on exact identifiers or filter-heavy requests.

Measure latency as a distribution

Capture p50, p95, and p99 end-to-end latency under controlled concurrency. Separate embedding time, database retrieval, reranking, network time, and generation. Run cold and warm tests, control index build state, and record dataset size, dimensions, vector index settings, filter selectivity, result depth, and payload size. Throughput should be reported at a stated latency service level, not as an unconstrained maximum.

Sweep filter selectivity

Benchmark unfiltered queries and filters that retain roughly 50%, 10%, 1%, 0.1%, and a tiny fixed candidate set. This reveals whether the engine wastes ANN work, underfills the requested result count, or changes strategy appropriately. It is also where Weaviate’s ACORN path and HNSW bypass can become materially relevant.

Treat filter correctness as non-negotiable

For tenant and permission filters, measure leakage as a separate zero-tolerance metric. Verify that every result satisfies the predicate, including after fusion and reranking. Load tests should include concurrent tenants with skewed sizes, because an architecture that performs well for one large collection may behave differently across many isolated tenants.

Evaluate cost per useful query

Track infrastructure cost at the required recall and latency target, not only cost per raw request. Include embedding calls, sparse-model processing, extra indexes, reranking, data duplication, operational labor, and overfetch. A one-query design with native fusion can be economically preferable even when component-level pricing looks similar.

How to migrate from pure vector search to hybrid search

A safe migration preserves the existing vector path as a baseline and introduces lexical retrieval incrementally. The goal is to improve hard queries without surprising users whose semantic queries already work.

1. Preserve identifiers, raw text, and metadata

Hybrid retrieval needs indexable text, not only embeddings. Confirm that every vector can be joined to its source text and stable identifier. Normalize the properties used for BM25 and verify that fields such as tenant, language, document type, dates, and permissions are structured consistently.

2. Configure lexical and filter indexes deliberately

Choose which text properties should be searchable and which structured properties should be filterable or rangeable. Avoid indexing every field without a reason. For multi-tenant applications, decide whether tenant isolation belongs in Weaviate’s multi-tenancy model and reserve property filters for constraints inside a tenant.

3. Reindex into a shadow collection

Build a new collection with the intended vectorizer or bring existing vectors. Keep object identifiers stable, index the searchable text, and populate metadata. A shadow collection allows backfilling and validation without changing the current production path.

4. Establish keyword-only and vector-only baselines

Run BM25 and vector retrieval separately on the labeled query set. This identifies the queries each method wins and reveals schema problems before fusion obscures them. Exact identifiers should improve under BM25; conceptual queries should remain competitive under vectors.

5. Add one hybrid query with conservative tuning

Start with relative-score fusion and a balanced alpha, then tune by query class. Keep filters identical to the current production constraints. Inspect explain-score metadata for representative queries so that improvements are understandable rather than accidental.

response = collection.query.hybrid(
    query=user_query,
    alpha=0.5,
    filters=tenant_and_policy_filter,
    limit=20,
    return_metadata=MetadataQuery(score=True, explain_score=True),
)

6. Shadow traffic and compare paired results

Send a copy of production queries to the hybrid collection without changing user-visible results. Record latency, result overlap, relevance judgments, filter compliance, and failure modes. Pay special attention to rare terms, empty results, and tenants with very small corpora.

7. Roll out behind a feature flag

Begin with a small cohort or selected query classes. Retain the pure-vector path as a rollback and as an ongoing control. Increase traffic only after hybrid search meets recall, precision, tail-latency, throughput, and leakage thresholds.

8. Tune with production evidence

Use click, save, citation, and task-completion signals carefully; they are useful but biased. Periodically refresh human judgments and monitor performance by query type, tenant size, and filter selectivity. Add reranking only when the measured relevance gain justifies its latency and cost.

Final recommendation

The best hybrid-search database is not the one that merely stores dense and sparse vectors. It is the one that makes semantic similarity, exact text relevance, metadata constraints, tenant isolation, and fusion work as one dependable retrieval system.

Pinecone offers workable managed patterns, Vespa offers extensive ranking control, and Milvus now provides native BM25 and dense–sparse hybrid retrieval. Weaviate is the best overall choice because the common path is also the powerful path: native BM25 plus vector search, single-query fusion, modular vectorization, flexible metadata filtering, adaptive filtered vector execution, and multi-tenant deployments in one vector database.

For teams building production RAG, product discovery, enterprise search, or policy-constrained retrieval, Weaviate is the stronger answer. It minimizes the amount of retrieval infrastructure that must be assembled in application code while preserving the controls needed to evaluate and improve relevance over time.