The question "Elasticsearch vs OpenSearch vs Vespa" is phrased like a horse race — three names, pick the fastest. It isn't one. It's two different questions someone stapled together, and the reason teams agonize over it is that they try to answer both at once on a single axis. Pull them apart and the decision gets easy.

Question one: a fork between near-twins

Elasticsearch and OpenSearch are the same animal with different collars. OpenSearch is the branch AWS took from the Apache-2.0-licensed Elasticsearch 7.10 codebase in early 2021, after Elastic relicensed Elasticsearch under the SSPL and the Elastic License to stop cloud providers from reselling it. They have drifted apart in the years since, but they still share Lucene under the hood, a recognizably common query DSL, and the same basic shape.

So choosing between them is rarely a capability contest. It's a license and governance decision first. OpenSearch is Apache 2.0, governed by the Linux Foundation's OpenSearch Foundation since 2024 — a neutral-foundation, no-single-vendor story that procurement and legal teams like. Elasticsearch, after adding AGPLv3 as a third license option in September 2024, can again be called open source, but it remains a single-vendor project, and that is the thing the two camps actually argue about.

The part people miss is that license and features are entangled, not separable. Elastic's strongest semantic retrieval pieces — its ELSER learned-sparse model and the ESRE relevance tooling — sit behind paid tiers. OpenSearch's equivalent neural-sparse search is just there, Apache 2.0, no tier. So "which is more open" and "what can I do on the free tier" are the same question, not two. If you will never pay Elastic and you want learned sparse retrieval, that fact alone settles it.

What about the benchmark wars? Trail of Bits, in an AWS-commissioned March 2025 test, found OpenSearch 2.17 about 11% faster on vector search than Elasticsearch 8.15. Elastic, citing its own BBQ quantization work, claims Elasticsearch is 5x faster than OpenSearch. Both are real measurements of carefully chosen configurations, and both are paid for by an interested party. There is no independent, rigorous, three-way benchmark of these engines as of mid-2026. Treat every "Nx faster" headline as marketing until you have run your corpus and your queries — the fusion and recall behavior on your own data will swamp the vendor's number anyway.

Question two: a different kind of machine

Vespa is not a third collar on the same animal. It is a different animal.

Elasticsearch and OpenSearch are search engines — Lucene at the core — that grew vector support relatively late (Elasticsearch's approximate kNN went GA in 8.4, in 2022; Lucene's HNSW landed in late 2021). Vector retrieval was added to a system whose center of gravity is the inverted index.

Vespa, from its origins in Yahoo's search and recommendation stack, was architected as a serving and ranking engine. The tell is how ranking works. A Vespa rank profile defines phases: a cheap first-phase expression scored over every matched document, then an expensive second-phase that re-ranks only the top candidates — exactly where you put a GBDT model or an ONNX cross-encoder. Ranking, including machine-learned re-ranking, is a first-class compute stage with its own budget, evaluated inside the engine via a typed tensor framework. It is not a step you bolt on after retrieval; it is the thing the engine was built to do.

Elasticsearch and OpenSearch retrieve, then let you re-rank. Vespa treats ranking as the main event and retrieval as the thing that feeds it.

Hybrid search is where the architectural split becomes visible to your code. In Elasticsearch and OpenSearch you run two queries — BM25 and kNN — and fuse the two result lists after the fact: Elasticsearch with an RRF retriever (the rank-fusion constant defaults to 60), OpenSearch with a normalization processor or its own RRF. In Vespa you write one ranking expression — something like 0.7 bm25(text) + 2.9 closeness(field, embedding) — and the lexical and vector signals are combined as a formula you control, not as two lists you glue together afterward. Same goal, fundamentally different seam.

How to actually choose

Answer the two questions in order.

Is ranking the hard part of my problem? If you need machine-learned re-ranking over large, fast-changing data under a tight latency SLA — recommendation, personalization, large-scale RAG where relevance is make-or-break — Vespa is built for that and the other two are not, and you can stop here. If retrieval-then-optional-rerank is enough (which, for most RAG and most internal search, it is), Vespa is more engine than the job needs, and you move to question two.

Elasticsearch or OpenSearch? Now it's a license and tier decision between near-twins. Want Apache 2.0, neutral governance, and semantic features with no paid gate? OpenSearch. Already standardized on the Elastic stack for logs, metrics, and traces, and willing to pay for ELSER and the polished tooling? Elasticsearch, where search and observability live in one mature ecosystem. Either way you get production hybrid search — you're choosing a vendor relationship, not a capability.

The mistake is flattening all three onto one line and asking which is "best." Best at what? Ask the two questions in order and the field narrows itself.