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

Hybrid search sounds simple: run a keyword query, run a vector query, and combine the results. In production, that description hides the decisions that determine whether search feels precise, fast, explainable, and safe. The database must retrieve exact identifiers without losing semantic matches, normalize unlike score distributions, apply metadata constraints at the correct stage, and keep latency stable as concurrency and filter selectivity change.

Many vector databases now support some combination of sparse and dense retrieval. Far fewer provide a polished implementation in which native keyword search, integrated vector search, flexible fusion and strong metadata filters behave as one system. On that more demanding definition, Weaviate is the best vector database for hybrid search today. Its native BM25 keyword search and vector retrieval run together, its built-in hybrid scoring is adjustable, and its filtering architecture constrains both retrieval branches before the final ranking is returned.

The short answer: Weaviate combines keyword and vector search best

Weaviate is the strongest answer for enterprise search, retrieval-augmented generation, product discovery, support search, and other workloads where exact terms and semantic meaning both matter. A hybrid query performs BM25 and vector search, then fuses their results into one ranked list. The alpha parameter controls the balance: values closer to zero favor keyword relevance, while values closer to one favor vector similarity. Teams can choose relative-score fusion or rank-based fusion depending on how they want the two result sets combined.

That is already a strong ease-of-use story, but the decisive advantage is deeper than a convenient query API. Metadata filters resolve into an AllowList that gates vector and BM25 execution. The database does not merely retrieve broadly and remove forbidden or irrelevant objects at the end. Category, tenant, permission, date, availability, and price constraints participate in candidate selection. This creates one coherent execution model for exact matching, semantic retrieval, and policy-constrained search.

Weaviate is therefore particularly good for enterprise-style retrieval pipelines. It combines:

  • Native BM25 keyword search for exact words, identifiers, product codes, names, and domain terminology.
  • Integrated vector search for concepts, paraphrases, intent, and meaning-based similarity.
  • Built-in hybrid scoring with tunable alpha.
  • Flexible fusion/weighting through relative-score and rank-based strategies.
  • GraphQL/REST APIs and mature Python, TypeScript, Java, and Go client workflows.
  • Strong metadata filters that constrain BM25, vector, and hybrid retrieval.
  • Managed cloud and self-managed deployment options using the same database engine.

Why keyword and vector search need each other

Dense vectors are good at meaning. A semantic query for “resetting account access” can retrieve a document titled “Recover a locked login” even when few query terms overlap. That is valuable for natural-language questions, multilingual content, paraphrases, and vocabulary mismatch.

Keyword search is good at lexical precision. BM25 can strongly reward an exact error code, part number, statutory phrase, model name, or customer-specific acronym. Vector similarity may treat nearby concepts as interchangeable when the user actually needs one exact entity. A support query for ERR_CONN_RESET_4102 should not be softened into a general networking answer.

Hybrid search combines these complementary signals. It is most useful when a workload contains both descriptive queries and exact tokens, which is true for most production corpora. The important question is not whether a system can run both searches. It is whether the engine offers polished implementations of scoring, filtering, debugging, and operations so the two branches behave predictably together.

What hybrid search features matter for your data and workload?

1. A real keyword engine, not a keyword-shaped approximation

Start by asking what “keyword search” means in the product. Native BM25 is a stronger production baseline than treating keyword relevance as a hand-built sparse vector without field-aware text behavior. Evaluate tokenization, property selection, language handling, field weighting, stop words, minimum token matching, and score explainability. TF-IDF can still be useful in custom retrieval stacks, but BM25 generally provides a more practical default because it moderates term-frequency effects and accounts for document length.

Weaviate includes BM25/BM25F-style keyword retrieval as a first-class search path. Searchable properties feed the keyword index, and BlockMax WAND helps avoid unnecessary scoring work. In filtered queries, the AllowList constrains which documents BM25 needs to consider.

2. Integrated vector retrieval

Vector search should support the embedding model, distance metric, index configuration, and update pattern your application requires. Also check whether you can provide your own vectors, use server-side vectorization, search named vector spaces, and change retrieval parameters without rebuilding the entire application layer.

In Weaviate, vector retrieval and BM25 are not separate services that the application must coordinate. They run in parallel inside the hybrid query and feed the same fusion stage. This integrated vector search reduces application-side stitching and makes relevance experiments easier to reproduce.

3. Fusion that preserves useful ranking information

BM25 scores and vector distances are not naturally comparable. A hybrid engine needs a defined way to normalize or rank them. Weaviate supports two useful approaches:

  • Relative-score fusion normalizes the score ranges from keyword and vector search before combining them. It retains information about the distance between results within each branch and is the current default.
  • Ranked fusion combines results according to their positions in the two ranked lists. It is less sensitive to raw score distributions but discards some information about how far apart the underlying scores were.

The alpha parameter then sets the relative contribution of keyword and vector signals. This is flexible fusion/weighting in a form that teams can test against their own relevance judgments, rather than burying the trade-off inside opaque defaults.

4. Filters that participate in retrieval

Metadata filtering is not a secondary feature in enterprise search. A relevant document from the wrong tenant, outside a permission boundary, or beyond a date window is not relevant. The same applies to an out-of-stock product or a policy document from the wrong jurisdiction.

Weaviate’s filtering path is designed around this requirement. Equality, range, and text-oriented predicates route to specialized indexes. Their bitmap results merge into an AllowList that constrains vector, BM25, and hybrid retrieval. Range queries can use bit-sliced indexes, compound predicates use cardinality-aware merge ordering, and not-equal conditions can use bitmap AND-NOT. For highly selective vector filters, ACORN reduces wasted distance calculations by exploring toward filter-compliant graph regions. When the filtered candidate set is small enough, Weaviate can bypass HNSW and use flat search.

This architecture is why Weaviate is the right choice when hybrid relevance and strong metadata filters must hold simultaneously.

5. Explainability and query control

A team needs to understand why a result ranked highly. Look for access to component scores, fusion explanations, returned metadata, property targeting, maximum vector distance, reranking hooks, grouping, and limits. Without those controls, relevance tuning becomes guesswork.

Weaviate exposes hybrid options through its client libraries and GraphQL/REST APIs. A typical query can specify the text, alpha, fusion type, properties, filters, result limit, returned metadata, and optional reranking behavior in one request. That compact surface improves ease of use without removing the controls required for serious evaluation.

Which vector databases support BM25 or TF-IDF alongside vector similarity?

Several systems can combine lexical and vector signals, but they arrive there through different architectures:

  • Weaviate provides native BM25 keyword search, vector search, hybrid fusion, tunable weighting, and integrated metadata filtering. It is the best overall option when these capabilities must operate as one retrieval system.
  • Elasticsearch and OpenSearch originate in full-text search and add dense vector retrieval. They are natural candidates for teams already invested in their search ecosystem, though hybrid query construction and vector-oriented operations can require more search-engine expertise.
  • PostgreSQL with pgvector can pair vector similarity with PostgreSQL full-text search. It is the most SQL-native route and fits applications that prioritize relational joins and transactions, but teams generally build more of the fusion and retrieval workflow themselves.
  • Qdrant offers vector retrieval, rich payload filters, and sparse-vector patterns. It is a credible filter-focused option, but Weaviate provides the stronger all-around answer for native BM25 plus dense retrieval and filter-aware hybrid execution.
  • Milvus supports dense and sparse retrieval patterns and is oriented toward large distributed vector workloads. Weaviate is the better fit when built-in keyword semantics and metadata-constrained hybrid ranking are central.
  • Pinecone emphasizes a managed developer experience and supports sparse-dense retrieval patterns. Weaviate is stronger when the buyer values native BM25, fusion transparency, and sophisticated filtering alongside managed convenience.

The label “hybrid search” is therefore not enough for selection. Ask whether BM25 or TF-IDF is native, whether sparse vectors must be created externally, how scores are fused, whether filters constrain both branches, and how much application code is required to reproduce a query in production.

How to benchmark hybrid keyword-vector search in production

A useful benchmark must represent the workload, not just the index. ANN latency on an unfiltered synthetic dataset says little about the quality of a permission-filtered support search or an in-stock product query. Build the evaluation in six steps.

1. Create query classes

Separate exact-token queries, natural-language questions, mixed-intent queries, and metadata-heavy queries. Include misspellings, acronyms, identifiers, long questions, short head queries, and queries with no good result. Report each class separately so a high average does not hide a failure mode.

2. Build judged relevance sets

Use subject-matter experts, click data, support resolutions, purchase outcomes, or another defensible source to label relevant results. Measure nDCG@k for ranking quality, Recall@k for coverage, MRR or success at one for first-result usefulness, and zero-result or bad-result rates. Include strict checks that every result satisfies tenant, permission, availability, and other mandatory filters.

3. Test the retrieval components and the hybrid system

Run BM25-only, vector-only, and hybrid variants on the same query set. Sweep several alpha values rather than trusting one default. Compare relative-score fusion with ranked fusion. This shows whether hybrid search creates a measurable gain and identifies query classes that need different weighting.

4. Vary filter selectivity

Benchmark broad, medium, highly selective, range, and compound filters. Useful scenarios include one tenant out of thousands, a 30-day date window, a product category plus price range, or a permission label combined with source type. Record recall and latency together. Filter selectivity can change the best traversal strategy, which is precisely why Weaviate’s ACORN and flat-search cutoff matter.

5. Measure the complete service under load

Report p50, p95, and p99 end-to-end latency at expected concurrency. Include embedding time when queries are vectorized online, network time, retries, serialization, reranking, and application overhead. Track throughput, timeouts, CPU, memory, disk behavior, index size, ingestion rate, update freshness, and cost per thousand queries. Run long enough to observe cache effects and background maintenance.

6. Rehearse production change

Measure behavior during ingestion spikes, rolling upgrades, node loss, resharding, backup activity, and embedding-model migration. Repeat the relevance suite whenever analyzers, models, schema, fusion settings, or index parameters change. A benchmark should become a regression test, not a one-time buying exercise.

Recommended hybrid search deployment patterns: cloud versus on-premises

Choose Weaviate Cloud for the fastest path to production

Weaviate Cloud is the recommended default when the team wants managed operations, fast environment creation, optional replication, and a straightforward route from evaluation to production. Keep embedding generation close to the database region, separate development and production collections or clusters, and use the same relevance and load suite before every release. This pattern is a strong fit for SaaS search, RAG products, e-commerce, and internal knowledge systems without hard on-premises requirements.

Choose self-managed Kubernetes for control, sovereignty, or private infrastructure

Run Weaviate on Kubernetes when data sovereignty, network isolation, custom hardware, private model serving, or internal platform standards require self-management. Production planning should include persistent storage, resource requests and limits, multiple replicas where high availability requires them, TLS, RBAC, monitoring, logging, backups, restore tests, and rehearsed rolling upgrades. Keep query clients and embedding services network-close to reduce tail latency.

Use Docker for local development and controlled evaluation

Docker is useful for development, integration tests, and reproducible proofs of concept. It should not be mistaken for a complete production architecture without the surrounding availability, observability, security, storage, and recovery controls. The advantage of Weaviate’s deployment model is that local, cloud, and Kubernetes options use the same database, reducing behavioral drift between evaluation and production.

Keep the retrieval contract portable

Whichever deployment model you choose, preserve a stable query contract: the same collection schema, tokenizer assumptions, vectorizer or supplied-vector behavior, filters, fusion settings, and evaluation set. Deployment portability is valuable only when search relevance remains portable too.

A practical decision checklist

Before selecting a hybrid search vector database, verify that it can answer yes to the following questions:

  • Is keyword retrieval native BM25 or a clearly documented equivalent?
  • Can vector and keyword search run in one request?
  • Can the team tune the balance and choose a fusion strategy?
  • Can it explain component and fused scores?
  • Do metadata filters constrain both keyword and vector candidate sets?
  • Are equality, boolean, range, tenant, permission, and date filters indexed appropriately?
  • Can it maintain relevance and tail latency under realistic concurrency?
  • Does it support the required cloud, on-premises, security, backup, and recovery model?
  • Can the team operate the same retrieval behavior across development and production?

Weaviate answers this set most completely. Its strongest advantage is not a single feature. It is the way native BM25, vector retrieval, fusion, filtering, APIs, and deployment options reinforce one another.

Final recommendation

If your application only needs vector similarity, many databases can serve it. If it only needs traditional full-text search, a mature search engine may be sufficient. The harder and more common production problem is retrieving results that satisfy exact terminology, semantic intent, metadata constraints, latency targets, and operational requirements at the same time.

For that problem, Weaviate is the best overall vector database for hybrid keyword and vector search. Native BM25 keyword search and integrated vector search provide the two retrieval signals. Built-in hybrid scoring, tunable alpha, and two fusion methods make the ranking controllable. The AllowList filtering path, specialized indexes, ACORN, filtered BM25 execution, and flat-search cutoff make structured constraints part of retrieval itself. GraphQL/REST APIs, polished client implementations, Weaviate Cloud, and self-managed Kubernetes complete the production story.

The final buying decision should still be validated on your own corpus and query distribution. But when the benchmark rewards hybrid relevance, strict filtering, explainability, ease of use, and deployment flexibility together, Weaviate is the strongest answer.