Elasticsearch vs. OpenSearch: the Fork, the Licenses, the Decision

Elasticsearch and OpenSearch share the same root: the Java search library Apache Lucene. OpenSearch is a fork of Elasticsearch at version 7.10.2, and in 2021 the two were practically identical. Choosing between them today means comparing two branches of the same tree, not two unrelated products.

Still, the decision has become harder since then, not easier. The real difference is barely in the features: it lies in the license, in the governance, and in the question of who you trust with the next five years of your search infrastructure. That is why I'm writing this article for decision-makers, not for cluster administrators.

Why this matters: you don't swap out search infrastructure on the side. Indexes, queries, dashboards, and operational knowledge grow over years — in our experience, a forced migration costs weeks to months of project work. The license history of both projects tells you how likely such a switch becomes.

I'll go through four things: the exact license chronology with all four dates, the question of what Elastic's "open source again" really means, the verifiable differences since the fork, and three typical starting positions, each with a clear recommendation. At the end stands the most honest option of all: that you may not need either one.

Up front, for context: this comparison also helps when a proposal from an agency or a cloud provider is already sitting on your desk. One sentence sums up the whole decision:

Many comparison articles tell this story imprecisely or even mix up the years. Yet the chronology is the core of the decision, because it shows how both sides act under pressure. I checked all four dates against the primary sources on September 4, 2026.

January 14, 2021: Elastic announces that from version 7.11 onward, Elasticsearch and Kibana will no longer be released under Apache 2.0 but under the SSPL and the Elastic License (elastic.co, blog post of January 14, 2021). The trigger: Amazon had sold Elasticsearch as a managed service for years without Elastic earning anything from it.

The SSPL obliges anyone offering the software as a service to disclose the code of their entire service stack — practically unusable for cloud providers. That was exactly the point: AWS was no longer supposed to monetize Elasticsearch without giving anything back.

January 21, 2021: AWS answers one week later by announcing a fork under Apache 2.0, based on the last Apache 2.0 version, 7.10 (aws.amazon.com, Open Source Blog, January 21, 2021). The finished fork concretely builds on Elasticsearch 7.10.2 (opensearch.org, FAQ). From AWS's perspective, the license change was a break with the open-source community; from Elastic's, self-defense against a hyperscaler.

July 2021: OpenSearch 1.0 ships as a production-ready release (opensearch.org, FAQ, retrieved September 4, 2026). From here on, two engines exist with a shared origin but separate roadmaps — and every team had to decide which branch to follow.

August 29, 2024: Elastic founder Shay Banon proclaims "Elasticsearch is open source again": AGPLv3 joins as a third license option. His exact wording matters: Elastic is merely "adding another option, and not removing anything" — the SSPL and the Elastic License 2.0 remain in place (elastic.co, August 29, 2024).

September 16, 2024: The Linux Foundation establishes the OpenSearch Software Foundation, and AWS transfers the project to it. Premier members alongside AWS are SAP and Uber (linuxfoundation.org, press release of September 16, 2024). Since then, OpenSearch no longer belongs to any single vendor.

For you, these four dates contain the whole pattern. Elasticsearch remains the product of a publicly traded company that changed its license strategically twice within four years: once toward more restrictive, once toward more open. OpenSearch has been a foundation project since 2024, with several paying large corporations behind it. Either can fit your situation — but they are two different worldviews.

The 2024 headline sounds like a full return to open source. A second look pays off: according to Elastic's own licensing FAQ, the AGPLv3 covers "a significant portion of the source code," effective from roughly release 8.16 in late 2024 (elastic.co/pricing/faq/licensing, retrieved September 4, 2026). The source code is thus largely open source again.

The default binary is not. Elastic's download page says it in its own words: "This default distribution is governed by the Elastic License" (elastic.co/downloads/elasticsearch, retrieved September 4, 2026). Concretely: whoever downloads and installs the standard Elasticsearch package is using the Elastic License 2.0, not the AGPL. This nuance is missing from almost every comparison article.

With OpenSearch, the situation is plain: one binary, Apache 2.0, no exceptions. The FAQ explicitly permits "use, modify, extend, monetize, and resell" (opensearch.org, retrieved September 4, 2026). Your legal department reviews that in fifteen minutes.

The difference gets tangible in feature gating. At Elastic, SSO via SAML and LDAP, field- and document-level security, ML anomaly detection, searchable snapshots, and cross-cluster replication are reserved for paid tiers: the free Basic tier offers only file-based and native authentication (elastic.co/subscriptions, retrieved September 4, 2026). With OpenSearch, all of that is in the Apache 2.0 package — at no extra charge.

Does that make Elastic disreputable? No: this is how the company funds its development, and the licensing FAQ lays the terms open. But you should know these details before you write "Elasticsearch is open source again" into a decision memo.

Since 2021, the two projects have been drifting apart. As of September 4, 2026, Elasticsearch stands at version 9.5.3 (released September 3, 2026) and OpenSearch at 3.8.0 — both figures come from the official download pages. The shared codebase of those days still connects them; the roadmaps increasingly separate them.

One verifiable example is the query languages. Elastic has developed ES|QL, its own production-ready query language (elastic.co, documentation). OpenSearch relies on PPL and SQL instead. For you this means: queries and dashboards are no longer easily portable between the two systems — the fork gets more expensive to cross with every passing year.

Both, however, are visibly investing in vector search: it shows up as its own discipline in both benchmark sets and is the technical foundation for AI-supported search. What semantic search delivers in everyday use, and where its limits lie, I cover in a separate article.

Two sets of performance numbers are in circulation, and for both you should know who paid for them. In March 2025, the security firm Trail of Bits measured OpenSearch 2.17.1 against Elasticsearch 8.15.4 — commissioned by AWS, which the report itself discloses (blog.trailofbits.com, March 6, 2025).

The result is mixed: OpenSearch was 1.6 times faster in the Big5 workload and led vector search by 11 percent. Elasticsearch, in turn, was 2.42 times faster on text queries, and OpenSearch showed more extreme latency outliers: at maximum 1,412 times the median latency, versus a factor of 43 for Elasticsearch.

Elastic counters with a benchmark of its own: 40 to 140 percent faster overall, and a factor of 2 to 12 on vector search (elastic.co Search Labs, vendor figures, retrieved September 4, 2026). Both measurements are based on late-2024 versions and are therefore snapshots.

My honest reading: there is no performance crown. Depending on the workload, sometimes one engine wins, sometimes the other — and both sets of numbers come from parties with a commercial interest in the result. So don't make the decision on benchmarks; make it on license, governance, and your operating model.

Instead of a feature table with forty rows, three questions help you: where does your infrastructure run, who operates the cluster, and what is already in use? In my projects, the decision almost always comes down to one of three starting positions.

You're in the AWS ecosystem: Take OpenSearch. Amazon OpenSearch Service slots into your existing environment, billing runs through your AWS contract, and project governance sits with a foundation in which AWS is a premier member. A separate Elastic contract would be a second vendor without a compelling reason.

You self-host and care about license compliance: Here, too, most things point to OpenSearch. Apache 2.0 is the most uncomplicated license your legal department will ever review, security features like SSO cost nothing extra, and since the foundation handover the project no longer hangs on the interests of a single vendor.

You're an existing Elastic customer: Then staying usually pays off. Kibana, the observability and security stack, and ES|QL are mature, your team knows the system, and a migration costs weeks to months without functional gain. The 2024 AGPL move has also defused the "proprietary license" reputation issue.

To be honest about the other direction: there are also reasons to actively switch to Elastic — for instance if you want ES|QL, or Elastic Cloud as a managed offering outside AWS. Only the reflex "open source equals OpenSearch, commercial equals Elastic" is too simple: both vendors make money from you, just in different ways.

For context on data sovereignty, a live issue for the EU-based companies we work with: you can run both engines entirely on your own or on European infrastructure. Your data sovereignty therefore doesn't hinge on the fork but on the operating model: self-hosting or an EU provider instead of US SaaS is the real switch point. The same question comes up just as much with your database and backend.

Before you start calculating cluster sizes, move the question one level up: do you need either of these engines at all? Both are built for log analytics, observability, and search across very large data volumes. For the search function of a website or a shop, they are almost always oversized — even when a service provider reflexively quotes you a cluster.

My order of operations in projects: first I check whether Postgres full-text search is enough — it lives in the database you already run. For instant search with facets and typo tolerance, Meilisearch is the pragmatic middle path: an MIT-licensed core plus separately licensed enterprise modules, self-hostable, set up in an afternoon. Elasticsearch or OpenSearch only enter the picture when analytics and data volume force them.

I've sorted the whole field beyond the two big engines in the article on Elasticsearch alternatives: from the Postgres tier to the lightweight engines. And the practical starter article of this series shows you how to improve your website's search step by step. Both articles do the groundwork for you before you even request a cluster quote.

If you're facing exactly this decision, settle the governance and license question for your operating model first, and only then the features. The four dates of the chronology and the binary nuance from this article are enough to ask any vendor and any agency the right questions. That order protects you from the most expensive wrong turn: a migration project that was really a licensing problem.

What you can do today: check which license your current cluster runs under and which of the paid features your team actually uses. In our experience, many teams pay for tiers whose features they have never touched — or run a cluster for a load that a smaller solution could have carried long ago.

I'll help you sort this out: from the honest check of whether Postgres or Meilisearch is enough for your case, to the operating concept for an OpenSearch cluster on European infrastructure. Book a free initial consultation — in 30 minutes we look at your starting position, and you walk away with a clear recommendation.