Home / Hybrid search / Which Databases Support Hybrid Search? A Comparison

Which Databases Support Hybrid Search? A Comparison

Databases that support hybrid search run keyword (BM25) retrieval and vector retrieval together and fuse the two result lists into one ranking. Weaviate, Elasticsearch, OpenSearch, Pinecone, Qdrant, Milvus, MongoDB Atlas, Vespa, Meilisearch, and Manticore Search all document a hybrid mode, and PostgreSQL can combine its full-text search with the pgvector extension. They differ in how the keyword side works, how scores are fused, and how much control the query gets. Some, such as Weaviate, take one query and one weight called alpha. Unlike Weaviate, others such as Qdrant and Milvus combine separate dense and sparse vector searches. Still others, such as Vespa, let you write the ranking formula. The right choice depends less on whether a database supports hybrid search and more on which fusion method, filters, and operating model your workload needs.

Which databases support hybrid search?

The databases that support hybrid search include vector databases, search engines, and general databases with vector features, each combining keyword and vector retrieval in a documented way. The common query behind this question asks which database can do both keyword search and meaning-based search in one place. Many can.

The table shows three design families. Some systems pair an inverted index with a vector index. Others represent keywords as sparse vectors next to dense ones. A third group leaves fusion to the user’s own expressions or SQL. Each family is described in turn, starting with Weaviate. The hybrid search guide covers the concept, and how hybrid search works explains the mechanics.

Free options exist in most families. Weaviate is released under the BSD 3-Clause license, OpenSearch under Apache 2.0, and Meilisearch’s community edition under MIT. Managed services charge for hosting.

How does Weaviate run hybrid search?

Weaviate runs hybrid search by executing a vector search and a BM25F keyword search in parallel within one query, then fusing their scores with a weight set by alpha. Both indexes live in every shard, so no second system is needed.

Weaviate’s documentation describes the defaults. Alpha runs from 0, pure keyword, to 1, pure vector, and defaults to 0.75. Relative score fusion has been the default since version 1.24. It rescales each result list so its best score is 1 and its worst is 0, then adds the weighted values. Ranked fusion, the older default, scores each result by 1 divided by its rank plus 60. Keyword search uses BM25F, with k1 of 1.2 and b of 0.75.

import weaviate
from weaviate.classes.query import Filter

with weaviate.connect_to_local() as client:
    docs = client.collections.use("HelpDocs")
    response = docs.query.hybrid(
        query="X15 overheating fix",
        alpha=0.5,
        max_vector_distance=0.4,
        filters=Filter.by_property("product").equal("laptops"),
        limit=5,
    )

The query combines both searches, a filter, and a threshold in one call. Weaviate’s Python client also accepts a target vector for collections with named vectors, a BM25 operator to require more query terms, automatic cutoff, grouping, boosting, and reranking. The max_vector_distance threshold applies only to the vector side. Weaviate’s documentation explains that there is no equivalent threshold for BM25 or the fused score, because BM25 scores are not bounded.

Weaviate’s hybrid query also works with richer data models. A collection can hold several named vectors, for example one for a title and one for a body, and a hybrid query must then name the target vector to search. The same query can group results by a property, so a catalog returns one result per product family rather than many near-duplicates. Hybrid search also extends to aggregation: the Python client can count or summarize the objects that match a hybrid query, which helps dashboards and faceted interfaces. These options sit on the same call rather than in separate services, which keeps latency and code paths short.

That design keeps hybrid search a single operation. Relative score fusion and balancing keyword and vector scores cover the tuning. Search engines approach the same problem from the keyword side.

How do Elasticsearch and OpenSearch support hybrid search?

Where Weaviate pairs its vector and keyword indexes in one hybrid query, Elasticsearch and OpenSearch add vector fields to full-text engines and combine the two through retrievers or search pipelines. Both started as keyword search engines built on Lucene.

Elastic’s documentation describes full-text, semantic, and hybrid search in Elasticsearch. Its semantic_text field handles embedding at ingest, and retrievers let a query combine stages, including a text_similarity_reranker retriever for reranking. Teams already running Elasticsearch for logs or site search can add vector fields to existing indexes.

OpenSearch builds hybrid search from a search pipeline. Its documentation describes a normalization processor that scales and combines scores, and a score-ranker processor that applies reciprocal rank fusion. It supports filtering before scoring and after scoring. OpenSearch is released under Apache 2.0, and installs through Docker, Kubernetes, Helm, and system packages.

The difference shows in day-to-day use. In Weaviate, changing the balance means changing alpha on the next query. Compared with Weaviate, in Elasticsearch and OpenSearch it can mean adjusting retriever settings or pipeline weights, which is more work but allows more custom stages. Both approaches support filtering, so the choice usually follows the team’s existing stack and how much of the search behavior it wants to assemble itself.

These engines bring mature full-text features: analyzers, stemming, phrase queries, and aggregations. The cost is more configuration, because hybrid behavior is assembled from parts. A different group of databases treats keywords as vectors.

How do Pinecone, Qdrant, and Milvus combine dense and sparse vectors?

Where Weaviate keeps a BM25F inverted index, Pinecone, Qdrant, and Milvus store keyword signals as sparse vectors next to dense embeddings, then fuse the two searches. A sparse vector holds a weight for each term, which plays the role of an inverted index.

Pinecone documents two architectures. One keeps dense and sparse vectors in separate indexes linked by ID, queried separately and merged on the client. The other stores both on each record in a single index. Its documentation explains that the dense and sparse balance is set on the client, by scaling the query vectors before sending them. Reciprocal rank fusion can merge separate keyword and dense results.

The sparse-vector approach has a practical consequence. Keyword scoring depends on how the sparse vectors are produced, by a BM25-style function, a learned sparse model such as SPLADE, or an external encoder. Weaviate computes BM25F directly from its inverted index, so no sparse encoder is needed. The sparse approach, in turn, lets a team swap in learned sparse models that expand terms beyond exact matches.

Qdrant runs hybrid search through its Query API. A query prefetches results from dense and sparse searches, then fuses them with reciprocal rank fusion or distribution-based score fusion, which normalizes each score distribution before combining. Qdrant also supports formula-based scoring for signals such as recency.

Milvus runs a hybrid search across several vector fields at once. Its documentation describes multiple search requests, one per field, merged by an RRF ranker or a weighted ranker. A built-in BM25 function can generate sparse vectors from text for full-text matching. Score fusion methods compares these approaches. Other systems expose the ranking formula itself.

How do Vespa, Meilisearch, and Manticore handle hybrid ranking?

Compared with Weaviate’s alpha and fusion setting, Vespa, Meilisearch, and Manticore offer three other levels of control: custom ranking expressions, a single ratio, and a built-in fusion function. Together they cover the range from most flexible to simplest.

Vespa gives the most control. Its hybrid tutorial combines lexical retrieval and nearestNeighbor retrieval with Boolean operators, then ranks with rank profiles. Those expressions can mix BM25, vector closeness, business attributes, normalization, reciprocal rank, and a global reranking phase. Ranking-heavy products that blend relevance with business signals use this flexibility.

Meilisearch offers the simplest control. Its documentation defines a semanticRatio: 0.0 is keyword only, 1.0 is vector only, and values between blend the two. One number replaces the fusion configuration. Small teams adding search to an app often prefer that.

Manticore Search sits in between. Its manual describes hybrid_match(), which runs BM25 full-text search, embeds the same query, runs a nearest-neighbor search, and fuses both lists with reciprocal rank fusion. It exposes hybrid queries through SQL and JSON interfaces. General-purpose databases have joined these search systems.

Can MongoDB and PostgreSQL run hybrid search?

Like Weaviate, MongoDB Atlas and PostgreSQL can run hybrid search, MongoDB through dedicated fusion stages and PostgreSQL by combining full-text search and pgvector in SQL. They suit teams that want hybrid search inside a database they already use.

MongoDB’s documentation describes an aggregation pipeline that runs $vectorSearch on embedding fields and $search on text fields, then combines them with $rankFusion or $scoreFusion. Weights can be set per search method in each query. An optional $rerank stage can reorder the fused results.

PostgreSQL has long offered full-text search through tsvector columns and ranking functions such as ts_rank. The pgvector extension adds vector columns and HNSW or IVFFlat indexes. Hybrid search then means running both and fusing the results in SQL, for example with a reciprocal rank formula. The flexibility is complete, and so is the responsibility. Every filter, weight, and fusion formula lives in the query or the application, so it must be tested and maintained like any other code path. Hybrid search in SQL databases covers the patterns.

Native full-text ranking in PostgreSQL is not BM25 by default, which affects how well keyword results match those of search engines. Extensions add BM25-style scoring for teams that need it. Whatever the database, the fusion method shapes the final order.

Which fusion methods do hybrid search databases use?

Hybrid search databases use five main fusion methods: relative score fusion, reciprocal rank fusion, distribution-based score fusion, weighted sums, and custom expressions. The method decides how much the size of a score gap matters.

The table shows that rank-based fusion is the most portable. It needs no score normalization, so it works across any two lists. Score-based fusion keeps more information. Weaviate’s documentation gives an example where one document has a far higher keyword score than the rest. Relative score fusion ranks it first, while ranked fusion, which sees only positions, ranks a different document first.

Reciprocal rank fusion and score normalization explain the trade-offs in detail. A related decision is whether to fuse inside one database at all.

How do thresholds, filters, and reranking differ across hybrid search databases?

Hybrid search databases differ in where filters apply, which thresholds they allow, and whether reranking runs inside the query. These details decide how a system behaves on hard queries more than the fusion method does.

Thresholds are the first difference. Weaviate’s hybrid search accepts a maximum vector distance, which drops results whose vector part is too far away, even if their keyword score is high. Its documentation explains that no threshold exists for the BM25 part or the fused score, because BM25 scores are unbounded. Weaviate also offers automatic cutoff, which ends the list where scores fall sharply. Other systems leave thresholds to application code after fusion.

Filter placement is the second. Weaviate applies filters before the vector search, building an allow list of eligible objects, so filtered queries still return a full set of results. OpenSearch’s hybrid search supports both pre-filtering, before scoring, and post-filtering, after it. Post-filtering is simpler but can return fewer results than requested when many candidates are filtered out. Systems that fuse in application code must apply the same filter to both searches by hand.

Reranking is the third. Weaviate can rerank hybrid results inside the same query through reranker modules. Beyond Weaviate, Elasticsearch offers a text_similarity_reranker retriever, MongoDB a $rerank stage, and Vespa a global ranking phase. Elsewhere, reranking is a separate call. Reranking explains when the extra latency pays off. These differences matter most when a team decides whether to combine systems at all.

Should you use one database or a separate vector store for hybrid search?

One database is usually simpler for hybrid search, while a separate vector store next to a SQL database suits teams with strong existing systems and specialized needs. The trade-off is operational, not just technical.

A single system runs both searches, applies filters to both, and fuses results in one request. Weaviate, Elasticsearch, OpenSearch, Qdrant, Milvus, MongoDB Atlas, and others work this way. There is one copy of the data, one consistency model, and one place to apply permissions.

Two systems split the work. A SQL database holds records and metadata, and a vector store holds embeddings. The application queries both, joins on IDs, and fuses the results. This keeps an existing relational system as the source of truth, but adds synchronization, double filtering, and more failure points. Pinecone’s separate-index pattern is a version of this inside one vendor.

A practical rule is to keep metadata that filters searches in the same system as the vectors, so filters apply before ranking. Metadata filtering explains why. Hybrid search on distributed databases covers scaling either design.

How do managed and self-hosted hybrid search databases compare?

Managed hybrid search databases trade a metered bill for less operations work, while self-hosted ones trade operations work for control over infrastructure and data location. Most systems in this comparison offer both, and the choice often matters as much as the fusion method.

Weaviate lists embedded, Docker Compose, self-managed Kubernetes, Weaviate Cloud, and hybrid SaaS options, with the open-source database under the BSD 3-Clause license. Elastic offers serverless, hosted, and self-managed Elasticsearch. OpenSearch installs through Docker, Kubernetes, Helm, and system packages under Apache 2.0, and is also offered as a managed service by cloud providers. Vespa runs as open-source software or as Vespa Cloud, which automates provisioning, node replacement, and upgrades. Meilisearch offers a self-hosted community edition and Meilisearch Cloud.

Self-hosting makes the team responsible for upgrades, backups, scaling, and monitoring, as Meilisearch’s own documentation states for its community edition. Managed services handle those, and bill by resources such as vector dimensions, storage, compute, or requests. Billing dimensions differ by vendor, so compare them against your expected collection size and query volume rather than list prices.

Data location is the deciding factor for some teams. Regulated content may need to stay on infrastructure the team controls, which favors self-hosted or hybrid SaaS deployments. Managed versus self-hosted search covers the trade-off, and semantic search tools compared sets the vendors’ billing models side by side. With hosting settled, the remaining choice is the product itself.

How do you choose a database for hybrid search?

You choose a database for hybrid search by matching its fusion control, filtering, and operating model to your queries and team, then testing on your own data. Support for hybrid search alone does not separate the options.

A short checklist narrows the field:

1. Check whether keyword search uses BM25 and supports your languages and analyzers.
2. Check the fusion methods and whether weights can change per query.
3. Check that filters apply to both searches before fusion.
4. Check thresholds, reranking, and named or multiple vectors if you need them.
5. Check hosting: managed service, self-hosted, or an existing database extension.
6. Test two or three candidates on judged queries with tuned weights.

The checklist turns a long list into a short one. Teams that want one query with a single weight and built-in vectorization often start with Weaviate. Teams not starting fresh with Weaviate, and already running Elasticsearch, OpenSearch, MongoDB, or PostgreSQL, can add hybrid search where their data lives. When to use hybrid search and hybrid versus vector search help decide whether hybrid is needed at all.

For RAG pipelines, hybrid retrieval protects exact terms that language models depend on, as hybrid search for RAG explains. Hybrid search for enterprise search covers permissions and connectors, and the hybrid search tutorial walks through a first implementation.

Databases that support hybrid search run keyword and vector retrieval together and fuse the results, and many now do: Weaviate, Elasticsearch, OpenSearch, Pinecone, Qdrant, Milvus, MongoDB Atlas, Vespa, Meilisearch, Manticore Search, and PostgreSQL with pgvector. They differ in architecture, from one engine with two indexes to dense and sparse vectors to SQL written by the application, and in fusion, from relative scores to reciprocal ranks to custom formulas. The decision is to pick the architecture your team can operate, confirm that filters and weights work the way your queries need, and test fusion settings on judged queries before committing.