What happened to Pinecone is happening across the category. Vectors are powerful, but they’ve become a feature, not a moat. MongoDB Atlas added vector search. PostgreSQL has pgvector. Oracle, Snowflake, Azure, and Google Cloud have all absorbed vector search into their existing platforms. As one industry analysis put it, vector search has become a checkbox item in cloud data platforms, not a standalone differentiator.

Interestingly, one of the vendors that made quiet but meaningful inroads as a vector store during this period wasn’t a vector database at all — it was Elasticsearch. Already deployed at scale across thousands of enterprises for traditional search, Elastic moved fast on dense vector support and ELSER, and many teams found themselves reaching for the platform they already had rather than standing up a new vector-specific infrastructure. While the market was still debating which pure vector DB would win, a search engine was becoming a credible answer to the same question.

This matters for anyone evaluating their search infrastructure today. The question “which vector database should I use?” is increasingly the wrong question. Vectors don’t live in isolation — they work alongside structured data, keyword indexes, filters, and business logic. The platforms that figured that out earliest are the ones pulling ahead.

Why hybrid search still matters — even in the age of LLMs

Even as vector search gained traction, practitioners kept running into the same wall: semantic understanding alone wasn’t enough. Here’s where a lot of organizations went wrong in 2023 and 2024:

they assumed that large language models and semantic vector search would make traditional keyword search obsolete. In theory, if the model understands meaning, why do you need exact keyword matching?

In practice, enterprise content is full of things that semantic models don’t handle well: product SKUs, error codes, model numbers, contract clause references, internal jargon, proper names. A search for “Error 221” shouldn’t return results for “Error 222” because they’re semantically adjacent. Pure vector search is great at capturing intent. It’s less great at capturing precision.

This is why hybrid search — combining BM25 keyword retrieval with dense vector search — consistently outperforms either approach alone across benchmark datasets and real-world deployments. This argument applies most directly to information discovery and enterprise content search — the use case where users are looking for specific documents, answers, or records.

For pure conversational AI applications, the calculus is somewhat different — though hybrid retrieval still produces better context than vector-only approaches. Garbage in, garbage out: the quality of what you retrieve shapes the quality of what the model generates.

How Elasticsearch emerged from the consolidation

The vector database shakeout didn’t happen in a vacuum, and Elasticsearch didn’t just survive it. It came out better positioned than before. While pure vector DB vendors were scrambling to add keyword search capabilities they’d never been built for, Elastic was doing the opposite: adding vector search to a platform that already had a decade of production search hardening behind it. That turned out to be the easier direction.

By the time the market consolidated, Elasticsearch had native dense vector support, ELSER for sparse neural retrieval, and dual fusion methods — RRF and weighted linear combination — for blending keyword and vector results. It had also been named a Leader in the 2025 Forrester Wave for Cognitive Search Platforms. The platform that enterprises had been running for log analytics, site search, and SIEM hadn’t just kept pace with the AI wave, it had embraced it.

The result is a market that has quietly settled around a smaller set of serious contenders. Elasticsearch and its AWS-managed sibling OpenSearch dominate general-purpose enterprise deployments. Apache Solr remains a legitimate choice, particularly in organizations with legacy investments and in academic and government contexts — and as we’ll cover shortly, it’s more capable on hybrid search than most people assume. Algolia has a strong, well-defended niche in managed e-commerce search. Azure AI Search serves organizations already deep in the Microsoft ecosystem.

So when enterprises today ask, “which search platform should I evaluate for hybrid search?” they’re really choosing between a small handful of mature options, not navigating a wide-open field. The more useful question is which of those platforms has the most complete, most production-ready hybrid search stack. That’s where the real differences emerge.

Not all “hybrid search” is the same thing

That distinction — having a complete hybrid stack versus approximating one — matters more than most vendor comparisons let on. When vendors say they support hybrid search, it’s worth asking what they actually mean. The term has become marketing shorthand for a wide range of things, some of which are genuine, some of which are closer to approximations.

True hybrid search requires a native, full-featured BM25 keyword engine and a native vector search engine running in the same system, with a proper fusion mechanism combining their results. That’s a shorter list than most people expect.

Elasticsearch and OpenSearch are the clearest examples of the real thing. Both have deep BM25 roots — Elasticsearch has been doing full-text search since 2010, with decades of Lucene refinement underneath. Both support Reciprocal Rank Fusion (RRF) for straightforward hybrid queries and weighted linear combination for finer control over how keyword and vector scores are blended. Where Elasticsearch pulls further ahead is ELSER — the Elastic Learned Sparse EncodeR — a sparse neural model that sits between traditional keyword matching and dense vector search, particularly effective on domain-specific enterprise content. Elasticsearch has also opened up support for third-party sparse models from Hugging Face, giving teams additional flexibility beyond ELSER itself.

Weaviate is a genuine contender and deserves to be on any serious evaluation list. It supports BM25F alongside vector search with solid fusion support. The architecture is vector-first with hybrid added on top — the inverse of Elasticsearch’s heritage — which matters depending on your workload.

Algolia’s NeuralSearch is a legitimate hybrid product, combining keyword matching with vector search using a neural hashing technique that keeps query latency low at scale. But it’s a managed SaaS platform built around e-commerce discovery. You trade relevance control and tuning depth for ease of deployment and a fast time to value. It’s a different product for a different buyer, not a weaker one.

Solr is more capable here than its reputation suggests, and the Apache Solr project has pushed back publicly on the misconception that it can’t do hybrid search. It can, including RRF fusion support, which was contributed to the project relatively recently. The real limitation isn’t capability, it’s operational: Solr requires you to handle embedding generation entirely in your application layer. There’s no built-in inference pipeline, no native sparse neural model equivalent to ELSER. For organizations already running Solr, hybrid is achievable. For greenfield deployments, the operational overhead is meaningfully higher.

Azure AI Search supports RRF hybrid and is a reasonable default if you’re already committed to the Azure ecosystem. The limitation is transparency: it’s a managed black box, and the relevance tuning options are considerably more constrained than what you get with Elasticsearch.

The dedicated vector databases, like Pinecone, have added sparse vector support and BM25 encoding, but there’s an asymmetry worth noting: it was considerably easier for Elastic to build good vector search on top of a mature keyword engine than it has been for vector-first platforms to build genuine keyword search depth. The linguistic infrastructure — analyzers, stemming, field weighting, synonyms — takes years to mature. You can’t encode your way around it.

Why Elasticsearch hybrid search has a genuine edge

Elasticsearch gives you more control over relevance than almost anything else on the market. You can tune field weights, customize analyzers, mix BM25 with dense vectors and sparse neural models in the same query, and inspect what the scoring math is actually doing at every level. That explainability and tunability is what separates search that works in a demo from search that works in production.

The same control extends to how you blend retrieval modes. RRF gives you a solid out-of-the-box fusion that requires no score normalization and works well across most workloads. Weighted linear combination gives you finer-grained control when you need to tune the balance between keyword precision and semantic recall for a specific domain. And ELSER adds a third retrieval mode that feeds into either fusion method — a learned sparse representation that often outperforms pure keyword or pure vector search on domain-specific enterprise content without requiring you to manage a separate embedding pipeline.

Few platforms give you all three levers in a single system. Fewer still let you inspect and debug the scoring at every level of the stack.

Where Elasticsearch doesn’t win

Being honest about trade-offs is the only useful way to evaluate search infrastructure, so here’s where Elasticsearch genuinely falls short.

At extreme vector scale — billions of high-dimensional vectors, multimodal retrieval, or workloads where pure similarity search dominates — some specialized architectures make credible claims about advantages built specifically for those use cases. Elastic has been investing heavily in closing that gap — DiskANN-based indexing and Better Binary Quantization (BBQ) were prominent themes at this year’s Elasticon — and the distance is narrowing. But if you’re operating at the very high end of vector scale, or working with multimodal content at volume, it’s worth an honest evaluation rather than assuming Elasticsearch gets you there automatically.

Cost is real and worth stating plainly. Elastic Cloud at scale is not cheap, and self-managed Elasticsearch requires genuine DevOps investment — skilled people, ongoing tuning, infrastructure management. The open source core can create a false impression that total cost of ownership is low. It isn’t, particularly as your index grows. On the storage side, Matryoshka Representation Learning (MRL) can help significantly — it allows teams to use much smaller vector dimensions without proportional loss in retrieval quality, which can make a real difference at scale. That said, some of the most compelling hybrid search features, including ELSER, still require a paid Elastic license rather than the free tier.

Personalization and multi-objective ranking are also not where Elasticsearch shines natively. If your search needs to simultaneously balance relevance, business merchandising rules, user history, and inventory signals, you’ll end up building significant custom logic on top of the platform — or looking at tools purpose-built for that kind of optimization. For e-commerce in particular, a managed platform like Algolia may simply be a better fit than engineering your way around Elasticsearch’s limitations in this area.

And if you genuinely don’t need keyword search at all — pure vector similarity is your entire use case — the full weight of Elasticsearch’s text machinery is overhead you’re paying for without benefit. There are simpler, lighter options worth considering for that specific scenario.

The right question to ask

The vector database category was built on a premise that turned out to be half right: vectors are essential for modern search. The part that didn’t hold up was that they’d displace everything else. Enterprises didn’t abandon keyword search. They needed both — and the platforms that understood that earliest are the ones that matter now.

That reframes the evaluation question. It’s not “which vector database should I use?” It’s “which platform has the most mature, most controllable, most production-ready hybrid search stack?” For most enterprise contexts, the answer is Elasticsearch — with OpenSearch a legitimate alternative for AWS environments and Weaviate worth consideration for vector-first architectures that need hybrid capability.

Pureinsights has been working with Elasticsearch since 2015 — we were at the first Elasticon. We’ve watched a lot of search trends arrive with fanfare and recede quietly. The pragmatic choice usually ages better than the exciting one.

Final thoughts

Also worth reading: Matt Willsmore’s Comparing Vector Search Solutions 2024 for a detailed side-by-side breakdown of the vendor landscape.  Or read about highlights from Elastic{ON} London 2026, which we recently attended.

If you’re evaluating hybrid search architecture or looking to improve an existing Elasticsearch deployment, we’d be happy to talk. If you’re ready to build, our Discovery platform can get you to a working hybrid search application faster — with significantly less custom coding overhead.

Hope this helps cut through the noise

— The Pureinsights Team