Elasticdump works with both Elasticsearch and OpenSearch, often with the same command and the same flags, which tends to raise an obvious question: if one tool can treat them as interchangeable sources and destinations, how different can the two products really be? The honest answer is that they share a common ancestor and a common query language, but they have been separate products, under separate licenses and separate governance, since 2021 — and the gap between them has been widening ever since.
The short history is that Elasticsearch and OpenSearch were literally the same codebase until early 2021, when a licensing change by Elastic prompted AWS to fork the last openly licensed version and continue it as OpenSearch. Everything people find confusing about the pair — the similar APIs, the incompatible versions, the arguments about which one is “really” open source — traces back to that split. This article covers the fork itself, what differs today in licensing, governance, and features, and where the practical compatibility boundary sits if you ever need to move data from one to the other.
One project until 2021
Until early 2021 there was only Elasticsearch, maintained by Elastic and distributed, together with Kibana, under the permissive Apache 2.0 license. Anyone could use it, embed it, or build a business on it, including offering it to customers as a managed service.
In January 2021, Elastic announced that Elasticsearch and Kibana would no longer be released under Apache 2.0. Starting with the 7.11 release, the code would move to a dual-licensing model: the Server Side Public License (SSPL) or the Elastic License 2.0, at the user’s choice. The practical target of the change was managed services — the new terms restricted offering Elasticsearch as a service to third parties. Version 7.10 became the last Apache 2.0 release of Elasticsearch.
AWS, which had been selling Elasticsearch as a managed service, responded by forking the code. It took Elasticsearch 7.10.2 and Kibana 7.10.2 — the final Apache-2.0 versions — and relaunched them as OpenSearch and OpenSearch Dashboards, keeping the Apache 2.0 license. The fork was announced in April 2021 and reached its 1.0 general-availability release in July 2021. It also absorbed AWS’s earlier Open Distro for Elasticsearch, a distribution AWS had first released in 2019.
AWS’s stated reason was to preserve a permissively licensed distribution that anyone could, in its words, “use, modify, extend, embed, monetize, resell and offer” as part of their own products and services. Whether you read the split as a dispute about open-source principles or about cloud revenue, the result is the same: from 7.10.2 onwards, there are two engines where there used to be one.
Version 7.10.2 therefore carries more weight than any other number in this story. It is the last release both products share, the point from which both version histories are measured, and — as the compatibility section below explains — the boundary that decides how painful moving between the two engines will be. The fork also doubled everything around the engine: Kibana became OpenSearch Dashboards, and from that point each side maintained its own clients, plugins, documentation, and release cadence.
Licensing and governance today
The license positions have shifted since 2021, and this is where most summaries go stale.
OpenSearch remains Apache 2.0 — a standard, OSI-approved open-source license with no service-offering restrictions. Its governance has changed, though: in September 2024, stewardship of the project moved from AWS to the newly formed OpenSearch Software Foundation, under the Linux Foundation. OpenSearch is now a foundation-governed project rather than one vendor’s product, even though AWS remains heavily involved.
Elasticsearch is still Elastic N.V.’s product, and its licensing is now a three-way choice: the Elastic License 2.0, the SSPL, or AGPLv3. The AGPLv3 option was added in August 2024 — a partial reversal of the 2021 move that restored an OSI-approved open-source license as one of the options. What it did not do is restore Apache 2.0: the original permissive terms under which 7.10 and everything before it shipped are not coming back, and the default license Elastic steers most users toward remains its own. The same story applies one layer up the stack, incidentally: the 2021 change covered Kibana as well as the engine, and Kibana’s forked counterpart, OpenSearch Dashboards, remains Apache 2.0 like the rest of its project.
So the accurate one-liner is: OpenSearch is Apache-2.0 software governed by a foundation; Elasticsearch is a single-vendor product available under your choice of a proprietary license, SSPL, or AGPLv3.
Where the license actually bites depends on what you do with the software. A team running a search engine for its own application feels the difference mostly as a procurement and policy question. A vendor embedding the engine in a product, or selling it as a managed service, sits exactly where the 2021 dispute was aimed — which is why AWS’s list of verbs in its fork announcement (“embed, monetize, resell and offer”) reads like a point-by-point answer to the restrictions Elastic introduced. The AGPLv3 option narrows the gap for users who need an open-source license, but copyleft terms bring their own obligations, and they are not the Apache terms either project started with.
What actually differs in the products
Five years of separate development show up most clearly in what each product bundles and what it charges for.
Features that are free in OpenSearch are paid tiers in Elasticsearch, or vice versa. OpenSearch ships its security features (including role-based access control), alerting, anomaly detection, a SQL interface, and cross-cluster replication as part of the free distribution. On the Elastic side, the core search and aggregation engine is free, but advanced machine learning, searchable snapshots, and some SQL clients sit in paid tiers. Both products have vector search with kNN, which matters for the current wave of embedding-based retrieval. Feature lists move over time, so treat any specific comparison as a snapshot of the day it was written — but the pattern has been stable: OpenSearch bundles more operational features at no cost, while Elastic holds some advanced capabilities back for subscribers.
The APIs have drifted. Both engines still speak the same query DSL and share most core REST APIs, inherited from their common 7.10.2 ancestor — a query written for one will usually run on the other. But the surfaces no longer match exactly. Elasticsearch 8.x removed mapping types entirely, something OpenSearch never had to do in the same way. Security administration lives under different paths: _security/... in Elasticsearch, _plugins/_security/... in OpenSearch. Plugins, clients, and dashboards have all diverged along similar lines — Kibana on one side, OpenSearch Dashboards on the other.
Side-by-side comparison
| Elasticsearch | OpenSearch | |
|---|---|---|
| Origin | Elastic’s product, continuous since before 2021 | Fork of Elasticsearch 7.10.2, launched 2021 |
| License | Elastic License 2.0 / SSPL / AGPLv3 | Apache 2.0 |
| Governance | Elastic N.V. (single vendor) | OpenSearch Software Foundation (Linux Foundation), since September 2024 |
| Visualization | Kibana | OpenSearch Dashboards (forked from Kibana 7.10.2) |
| Security features | Core free; advanced features in paid tiers | RBAC and security bundled free |
| Alerting / anomaly detection | Partly paid tier | Bundled free |
| Vector (kNN) search | Yes | Yes |
| SQL | Partly paid tier (some clients) | Bundled free |
| Cross-cluster replication | Paid tier | Bundled free |
| Shared ground | Query DSL and most core REST APIs, from the common 7.10.2 ancestor | Same |
The ecosystems differ. Choosing one is also choosing a vendor relationship, a support channel, a managed-service market, and a plugin ecosystem. Those are legitimate deciding factors, and for many teams they matter more than any single feature row.
Compatibility: the 7.10.x boundary
If the two products share an ancestor, can you move data and workloads between them freely? Only at one specific point in their history.
Migration from Elasticsearch 7.10.x or earlier to OpenSearch is generally straightforward. Because OpenSearch is Elasticsearch 7.10.2 at its root, its early versions could read the older product’s data directly: moving via snapshot and restore, or reindexing from a remote cluster, works because the on-disk and API formats still line up. This is the one boundary where “they’re basically the same product” is a fair description. The trade-offs between the snapshot route and a document-level copy are covered in Elasticdump vs Snapshot and Restore.
Migration from Elasticsearch 8.x or 9.x is a different story. Years of divergence — removed mapping types, changed APIs, different security models — mean data and queries usually require real adaptation work, not a copy operation. Going the other direction, from a recent OpenSearch to a recent Elasticsearch, runs into the same drift from the opposite side.
In practice, that adaptation work has recognizable parts. Mappings written for 8.x assume a world without mapping types, which is fine, but anything inherited from older indices may carry constructs the other side rejects. Security configuration cannot be carried across as-is, because the two products administer users and roles through different API paths, so it gets rebuilt rather than copied. Dashboards and visualizations are rebuilt in OpenSearch Dashboards or Kibana rather than transferred. And every client library, ingest pipeline, and plugin in the stack has to be checked against the target, because each has spent years tracking only one of the two products. None of this is exotic — it is ordinary migration work — but it is why “the data is just JSON” understates the job.
There is also a category question underneath the compatibility one. Teams migrating often discover their real question is not “which engine” but “what role does this engine play in our stack” — and whether Elasticsearch counts as a database at all turns out to shape the migration design more than any API difference.
Three misconceptions worth dropping
“OpenSearch is just old Elasticsearch.” It forked from 7.10.2 in 2021, but it has had years of independent development since — its own releases, its own features, its own roadmap. As one comparison puts it, five years of separate development have turned one search engine into two different products.
“Elasticsearch is fully open source again.” The accurate version has three parts: Apache 2.0 until 7.10; SSPL and the Elastic License from 7.11, neither of which is an OSI-approved open-source license; and AGPLv3 added as an option in 2024, which is open source but copyleft — a very different set of obligations from the Apache terms the project started under.
“They’re interchangeable, so migration is copy-paste.” True-ish only at the 7.10.x boundary. Every version after that adds drift, and a migration between current versions of the two products is a project to plan, not an afternoon’s copy job. The general workflow for moving index data between clusters — whatever they run — is set out in how to copy data from one Elasticsearch cluster to another.
Where ElasticDump fits in
ElasticDump added OpenSearch support in version 6.76.0, and it auto-detects which flavour of cluster it is talking to (a --force-os-version option, defaulting to 7.10.2, exists for cases where detection needs help). Because it moves documents through the REST APIs and re-indexes them at the destination, it is largely indifferent to the licensing and governance story above — the same dump-and-load workflow applies to an Elasticsearch source and an OpenSearch target, or the reverse. That makes it one of the practical routes across the compatibility boundary described above, particularly from newer Elasticsearch versions where snapshot compatibility has run out. One caveat from the managed world: AWS OpenSearch Serverless does not support the Scroll API, so ElasticDump works there through plain search and bulk indexing instead — functional, but AWS notes it may affect performance.
FAQ
Is OpenSearch free?
Yes. OpenSearch is distributed under the Apache 2.0 license, and its bundled features — security, alerting, anomaly detection, SQL — are part of the free distribution rather than a paid tier.
Is Elasticsearch open source?
Partly, and it depends on the version and the license you pick. Releases up to 7.10 were Apache 2.0. From 7.11 the choices were the Elastic License 2.0 or SSPL, and since August 2024 AGPLv3 has been a third option. It is not Apache-licensed anymore under any version of the current arrangement.
Can I migrate from Elasticsearch 8.x to OpenSearch with a snapshot?
Not directly — snapshot migration depends on version compatibility, and 8.x has diverged too far from OpenSearch’s 7.10.2 roots. The realistic routes are reindexing or a document-level copy, with query and mapping adaptation expected along the way.
Which one should a new project choose?
There is no universal answer, and anyone who gives you one without asking about your constraints is selling something. License terms, whether you want foundation governance or a single vendor, which managed services you use, and which features you need for free are the questions that actually decide it. The engines’ core search capabilities remain close.
Does ElasticDump work with both?
Yes — OpenSearch support arrived in version 6.76.0, and the tool auto-detects the cluster type, so the same workflow covers Elasticsearch, OpenSearch, and copies between them.
Is OpenSearch still an AWS project?
Not anymore. AWS created and stewarded it after the fork, but in September 2024 the project moved to the OpenSearch Software Foundation under the Linux Foundation. AWS remains a major contributor and sells it as a managed service, alongside other vendors — which is roughly the outcome the fork was meant to produce.
Can the same queries run on both engines?
Usually, yes. Both products inherited the same query DSL and most core REST APIs from their shared 7.10.2 ancestor, so ordinary search and aggregation queries tend to run unchanged on either. The differences show up around the edges — administration, security, and newer version-specific features — rather than in everyday querying.
Conclusion
Elasticdump can treat the two engines almost interchangeably because it works at the document level, but the products themselves should not be confused: one codebase until 2021, then a licensing split that produced an Apache-2.0, foundation-governed OpenSearch on one side and Elastic’s triple-licensed Elasticsearch on the other. For day-to-day search work they remain close cousins with a shared query language. For licensing, governance, bundled features, and any migration that starts from a current version, they are distinct products — and the 7.10.2 fork point is the line that decides how easy crossing between them will be. Before assuming anything about a cluster you have inherited, check which side of that line it sits on, and which version: those two facts predict more about your options than any feature comparison.