Vector Database Hybrid Search

Hybrid vector search runs two retrievers against the same query. The lexical side scores exact term matches, almost always using BM25 — the ranking function documented in Wikipedia’s Okapi BM25 entry — which excels at identifiers, part numbers, and rare terms. The semantic side embeds the query and finds nearby vectors using an approximate nearest-neighbor index, typically HNSW from the 2016 paper.

Reciprocal Rank Fusion (RRF)

merges by position rather than score. Each result gets points based on where it ranked in each list, and those are summed. RRF’s advantage is that it sidesteps an awkward problem: BM25 scores and cosine similarity live on completely different scales, so comparing them numerically is meaningless. RRF needs no tuning and works well out of the box, which is why it’s the common default.

Weighted score fusion

normalizes both score types onto a shared scale and blends them with a weight — 60/40 favoring semantics, for example. More control, more maintenance, and the normalization is fiddly enough that most teams should start with RRF and move only when relevance data justifies it.

1. Weaviate — the native hybrid leader

Weaviate fuses BM25 keyword scoring, dense vectors, and metadata filtering in a single query, with an adjustable alpha parameter controlling the semantic-lexical balance. It also bundles vectorization modules, so you can insert raw text and get embeddings automatically rather than running your own pipeline. On its Shared Cloud tier, BM25 is included with no separate billing.

Pricing is dimension-based — roughly $0.095 per million dimensions stored per month on Shared — which means higher-dimension embeddings cost proportionally more. A 10M-vector index lands around $135/month, though binary quantization drops that toward $30. Query latency runs 30–70ms, with hybrid adding roughly 10–20ms.

Verdict: if hybrid vector search is your primary requirement, this is the default choice.

2. Qdrant — best filtered hybrid performance

Qdrant supports hybrid retrieval through its Query API with server-side fusion, and its real distinction is filtered search performance. Rust-based with rich payload filtering, it maintains low latency when constraints are applied — where several competitors see 2–3× slowdowns. Since virtually every production query carries filters, this matters more than headline benchmarks suggest.

Cloud pricing starts around $0.014/hour per node, landing near $65/month at 10M vectors. Latency runs 15–30ms in-memory. Verdict: best when hybrid vector search must survive heavy metadata filtering.

3. Milvus — hybrid vector search at billion scale

Milvus supports multi-vector search with fusion, and is engineered for the largest deployments — highest write throughput of the major options thanks to its distributed architecture, with disk-based indexing that saves substantial RAM cost at scale. Operationally heavier than the alternatives. Verdict: the choice past a billion vectors.

4. Elasticsearch / OpenSearch — mature hybrid, heavy operations

These arrive at hybrid vector search from the opposite direction: decades-old BM25 implementations with dense-vector kNN and RRF added. If you already run Elasticsearch, hybrid capability may already be in your stack. The cost is cluster operations you own permanently. Verdict: strong if you’re already invested.

5. Pinecone — hybrid via sparse-dense vectors

Pinecone supports hybrid through sparse-dense vector pairs rather than a built-in BM25 engine, which means you generate sparse representations yourself. Fully managed with no self-hosting option, serverless pricing at $0.33/GB/month storage, $8.25 per million read units, and $2.00 per million write units. Serverless recall is fixed near 90% with no tuning available. Verdict: workable, but hybrid is less native than Weaviate’s.

6. pgvector — hybrid you assemble

Postgres already has full-text search. Add pgvector and you have both halves — but you write the fusion query yourself, typically combining ts_rank and vector distance in SQL. No extra infrastructure and no license cost beyond the database you already run, around $45/month on RDS at 10M vectors. Verdict: genuinely good below a few million vectors if you’re comfortable writing the SQL.

7. Vespa — search-first hybrid vector search

Vespa was a search and ranking engine before vectors were fashionable, so hybrid vector search is native rather than bolted on, with sophisticated ranking expressions. Steeper learning curve. Verdict: powerful for teams who’ll use the ranking depth.

Test the hybrid vector search exact-match floor.

Query real SKUs, part numbers, and model codes. They must resolve literally, every time. This is the entire reason you’re adding hybrid.

Test with filters applied.

Take your most restrictive real facet combinations and measure p95 and p99. Filtered performance is where platforms diverge most, and unfiltered numbers flatter everyone equally.

Ask which fusion method they use.

RRF or weighted scoring, and how you’d change the balance. Confident vendors answer in a sentence; vague answers usually mean less hybrid capability than the marketing implies.

Check whether tuning is possible.

Can you shift the semantic-lexical balance per query type? Technical catalogs usually want more lexical weight; descriptive categories want more semantic.

Measure recall against ground truth.

Approximate search degrades silently — no error, just slightly worse results. Build a brute-force ground-truth set on a sample of real queries and check periodically. Our nearest neighbor search guide covers why, and search relevance metrics covers the scoring.

Latency.

Two retrievers plus fusion is more work per query — typically 10–20ms extra on Weaviate. Well-engineered systems still land under 200ms, but benchmark under real load rather than trusting an idle index.

Hybrid vector search means two indexes to maintain.

A lexical index and a vector index, both needing updates when content changes. Our real-time indexing guide covers keeping both current.

More configuration surface.

Embedding model, fusion method, weights, candidate depth, index parameters. More knobs means more ways to misconfigure.

Reindexing on model changes.

Swap embedding models and you re-embed everything. The lexical side is unaffected, which is a small mercy — the vector embeddings storage guide covers planning for this.

Start with RRF and leave it alone.

Reciprocal Rank Fusion needs no tuning and performs well across query types. Resist adjusting anything until you have relevance data proving a specific change helps.

When you do move to weighted fusion, tune per catalog, not per intuition.

Technical catalogs dense with part numbers usually want more lexical weight. Fashion, home, and gifting catalogs — where shoppers describe rather than name — want more semantic. The right split for your data is an empirical question, and hand-picking a few queries that “look better” is how relevance quietly degrades.

Consider per-query-type balancing.

Sophisticated implementations detect query shape and shift the balance dynamically: a short alphanumeric string leans lexical, a full sentence leans semantic. This delivers more than a single global weight, and a few platforms support it natively.

Watch candidate depth.

How many results each retriever returns before fusion — commonly 50, 100, or 200. Too shallow and good matches never reach fusion; too deep and you add latency while feeding noise to any downstream reranker.

Score every change against a judged set.

Build 200–500 real queries from your logs with relevance judgments, and score offline before shipping. Then confirm with a live split. Without that, every tuning decision is an opinion wearing a number.

What is hybrid vector search?

Hybrid vector search runs keyword matching and vector similarity retrieval in parallel against the same query, then fuses the two ranked lists into one. It combines the exact-match precision of BM25 with the meaning-awareness of embeddings, so both SKUs and descriptive natural-language queries resolve correctly.

Which vector databases support hybrid search natively?

Weaviate leads with single-query BM25 plus vector fusion and an adjustable alpha parameter. Qdrant supports it with strong filtered performance, Milvus at billion scale, and Elasticsearch and OpenSearch via mature BM25 plus kNN with RRF. Pinecone uses sparse-dense vector pairs, and pgvector requires you to compose the fusion query in SQL.

What is Reciprocal Rank Fusion?

RRF merges two ranked lists by each result’s position rather than its raw score, avoiding the problem that BM25 scores and cosine similarity use incompatible scales. It requires no tuning, which makes it the common default in hybrid implementations.

Does hybrid search slow down queries?

It adds work — typically 10–20ms on top of vector-only retrieval — because two retrievers run plus a fusion step. Well-built systems still return results under 200ms. Benchmark at p95 and p99 with your real filters under concurrent indexing load.

Do I need hybrid search, or is vector search enough?

If your content contains exact identifiers — SKUs, part numbers, model codes, ISBNs — you need hybrid, because pure vector retrieval approximates on those. If your content is purely descriptive prose with no identifiers, vector-only may suffice.

Can I add hybrid search to pgvector?

Yes. Postgres includes full-text search, so you can combine ts_rank with pgvector distance in a single SQL query and implement your own fusion. It works well below a few million vectors and requires you to write and maintain that query yourself.