Hybrid search improves retrieval coverage but adds a second retrieval path and its operational costs
Compared with dense-only retrieval, hybrid search normally costs more in three places: indexing, storage, and query execution. You maintain both a dense vector index and a sparse index, store both representations, and execute two candidate-generation paths before fusion. The sparse representation can be compact when it has few non-zero entries, but its index still requires memory and maintenance. At query time, generating both representations and searching both branches increases CPU, I/O, and latency, especially when candidate limits are high. The benefit is better robustness across semantic and lexical query classes. My production approach is to measure marginal relevance gain per millisecond and per GB rather than assuming hybrid is always worth the overhead. A common mistake is comparing only top-1 relevance and ignoring p95/p99 latency, ingestion throughput, and infrastructure cost.
Indexing cost increases because the system maintains both dense and sparse retrieval structures and any associated payload indexes.
Storage increases because each point carries an additional sparse representation and its index structures, although sparse storage depends strongly on the number of non-zero entries.
Query latency usually increases because both branches execute and their candidate lists must be fused; candidate depth is a major tuning parameter.
Trade-off: hybrid can materially improve recall for exact terms and rare vocabulary. A simpler dense-only design may still be preferable when queries are mostly semantic, latency is extremely constrained, or the lexical gain is negligible.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
