Elasticsearch vs. OpenSearch: Differences After the Fork

1. The history of the fork: how it happened in 2021

In January 2021, Elastic announced that it would stop releasing Elasticsearch and Kibana under the Apache 2.0 license starting with version 7.11, switching instead to a dual license consisting of the Elastic License and the Server Side Public License, or SSPL. Elastic cited AWS in particular as the reason, since AWS offered its own, largely identical Elasticsearch distribution as a managed cloud service without contributing significantly to the open source project. Elastic saw this as a business model that profited from the open code without co-funding its development.

AWS responded a few weeks later by announcing OpenSearch, a fork of the last Apache 2.0 licensed Elasticsearch state, version 7.10.2. Together with other companies from the Elasticsearch ecosystem, including Aiven, Red Hat and SAP, OpenSearch continued under Apache 2.0 and its governance was gradually moved into a more independent structure. The fork point in spring 2021 thus marks the beginning of two separate development paths that had shared the same code base for years before.

For operators of existing Elasticsearch clusters, the announcement meant a fundamental decision: stay with Elasticsearch and accept the new license, or switch to OpenSearch and commit to the Apache 2.0 line. This decision affected not just licensing questions but also which of the two now separately evolving projects to follow in the long run.

2. SSPL, Elastic License and Apache 2.0 in detail

The Server Side Public License, originally developed by MongoDB, requires anyone offering the licensed software as part of a hosted service to disclose the complete source code of the entire service stack, not just the software itself. This clause is deliberately broad enough that it effectively forces cloud providers like AWS to either publish their entire own infrastructure code or forgo hosting the SSPL licensed software. Critics therefore do not consider the SSPL a genuine open source license in the sense of the Open Source Initiative, because it restricts that freedom.

The Elastic License, the parallel option to the SSPL, is a proprietary source-available license that permits usage but explicitly prohibits certain commercial uses such as offering the software as a managed service. Both license options thus differ fundamentally from the original Apache 2.0 license, which recognizes practically no usage restrictions, not even for commercial hosting by third parties. OpenSearch consistently stayed with Apache 2.0, which makes the fork attractive to companies that value an uncontested, permissive license.

For practical purposes, it is important to note: the license choice primarily concerns companies that want to resell the software itself as a cloud service. A company that runs Elasticsearch or OpenSearch exclusively internally for its own applications is generally not directly affected by the restrictions of the SSPL or Elastic License, but should still have the license terms reviewed legally before committing to one of the two lines.

# Timeline overview, useful as a quick reference in migration decisions

# 2021-01: Elastic announces dual licensing (Elastic License / SSPL)
#          starting with Elasticsearch and Kibana 7.11
# 2021-04: AWS announces OpenSearch, forked from the last
#          Apache 2.0 release, Elasticsearch 7.10.2
# 2021-09: OpenSearch 1.0 released under Apache 2.0
# 2024-08: Elastic re-licenses Elasticsearch and Kibana under
#          AGPL (in addition to Elastic License and SSPL)

3. Elastic's return to open source in 2024 and what it means

In August 2024, Elastic announced that it would also make Elasticsearch and Kibana available under the GNU Affero General Public License, or AGPL. The AGPL is officially recognized as an open source license by the Open Source Initiative, unlike the SSPL. Elastic has since offered three parallel license options: the proprietary Elastic License, the SSPL, and the AGPL, letting users pick whichever fits them. This reversal, however, did not fundamentally change the original dispute, since the core criticism of the SSPL model remained, and the fork into OpenSearch had long since become an independent project with its own roadmap.

For teams that had already migrated to OpenSearch, the AGPL announcement changed little in practice, since migrating back to Elasticsearch would mean the same effort as the original switch. For teams that had stayed with Elasticsearch, the AGPL option opened up a formally recognized open source license as an alternative to the SSPL, which is particularly relevant for companies whose internal compliance policies only permit OSI recognized licenses.

4. Architectural commonalities: what is still identical

Despite the divergence since 2021, both Elasticsearch and OpenSearch still build on Apache Lucene as the core search and indexing engine. That means fundamental concepts such as inverted indices, segment merging, analyzer chains, and the general query DSL structure still work in structurally similar ways in both systems. Anyone who has understood the basics of mapping, shards, and aggregations in Elasticsearch finds their way around OpenSearch quickly, because the REST API still shares the same common origin for the most part.

Basic operational concepts such as cluster discovery, shard allocation, and the rolling upgrade procedure also follow similar principles in both systems, since these mechanisms originate from the shared code base before the fork and have since evolved in parallel but independently. This structural closeness is an important factor that makes migrations between the systems technically feasible, even if they require effort.

// Identical core query DSL in both systems, unchanged since the fork
GET /products/_search
{
  "query": {
    "bool": {
      "must": [{ "match": { "name": "wireless headphones" } }],
      "filter": [{ "term": { "in_stock": true } }]
    }
  },
  "aggs": {
    "by_brand": { "terms": { "field": "brand" } }
  }
}

5. Feature divergence: vector search, ML and security

Since the fork, both projects have developed independent features that do not exist, or only exist in a different form, in the other system. For vector search in semantic applications and retrieval-augmented-generation scenarios, Elasticsearch has invested in the Elastic Learned Sparse Encoder and deep integration of machine learning models into its own platform, while OpenSearch has taken an alternative but functionally overlapping path with its own k-NN plugin and neural search functionality. Both approaches now support dense vector search, but differ in implementation details, default algorithms, and integration depth with external embedding models.

For security functionality, once a central point of contention because Elastic offered X-Pack security features under a paid tier for a long time, the picture has shifted: OpenSearch integrates the OpenSearch Security plugin with role-based access control for free by default, while Elastic now also offers basic security features such as TLS and role-based access control in its free basic license. Advanced security features like SAML integration or field-level security remain partly reserved for paid tiers at Elastic, while OpenSearch keeps most comparable functionality freely available.

Another field of divergence is the observability and dashboard layer: Kibana at Elasticsearch and OpenSearch Dashboards at OpenSearch have increasingly grown apart visually and functionally, with different visualization types, alerting mechanisms, and plugin ecosystems. Anyone relying heavily on specific Kibana visualizations, or conversely on OpenSearch specific dashboard plugins, should explicitly check this dependency before a migration decision.

// Elasticsearch: dense vector field for semantic search
PUT /articles
{
  "mappings": {
    "properties": {
      "embedding": {
        "type": "dense_vector",
        "dims": 384,
        "similarity": "cosine"
      }
    }
  }
}

// OpenSearch: comparable k-NN vector field
PUT /articles
{
  "settings": { "index.knn": true },
  "mappings": {
    "properties": {
      "embedding": {
        "type": "knn_vector",
        "dimension": 384
      }
    }
  }
}

6. Ecosystem and governance: foundation versus company

An often underestimated difference lies in the governance structure. Elasticsearch is developed and controlled by Elastic N.V., a publicly traded company that holds final decision-making authority over roadmap, licensing, and release cycles. OpenSearch was formally moved into the OpenSearch Software Foundation under the umbrella of the Linux Foundation in 2024, with the stated goal of distributing governance across multiple companies and independent contributors instead of concentrating it in a single commercial actor.

This structural difference influences how decisions about new features, breaking changes, and deprecations are made. At Elasticsearch, Elastic as a company ultimately determines the direction, which enables fast, consistent product decisions, but also means that the company's commercial interests can directly influence the roadmap, as the 2021 license change demonstrated. At OpenSearch, decision-making runs through a foundation model with multiple participating companies, which is potentially slower but less dependent on the interests of a single actor.

7. API compatibility and client libraries

Right after the fork, the REST APIs of Elasticsearch 7.10.2 and the resulting OpenSearch were practically identical, which made simple migrations with minimal code effort possible. Since then, both projects have independently introduced new endpoints, parameters, and behaviors, so API compatibility gradually decreases with every new major version. Elastic has also introduced technical measures in newer versions that make it harder for third-party clients pretending to be OpenSearch to connect, which has been controversially discussed in the community.

For application developers, this means concretely: official client libraries are now product specific, the Elasticsearch Python client is no longer guaranteed to be compatible with newer OpenSearch clusters, and vice versa. Anyone writing an application meant to theoretically run against both systems should limit themselves to the lowest common denominator of the query DSL and test regularly against both target systems, instead of relying on permanent API identity.

# Separate, product-specific client libraries since the fork
pip install elasticsearch      # official Elasticsearch Python client
pip install opensearch-py      # official OpenSearch Python client

# Both expose a similar surface, but version pinning matters:
# elasticsearch==8.x targets Elasticsearch 8.x servers only
# opensearch-py targets OpenSearch clusters, compatibility with
# Elasticsearch servers of the same era is not guaranteed

8. Migration considerations: when a switch pays off

A migration from Elasticsearch to OpenSearch or vice versa is technically feasible in principle, but not trivial, because no direct rolling upgrade path exists between the systems. In practice, a switch means: transferring data into the new cluster via reindex or snapshot-restore procedures, checking all used query DSL constructs for compatibility, rebuilding dashboards and alerting rules manually, and swapping client libraries in the application code.

The effort pays off primarily when license questions are directly relevant to a company's own business model, for example because a company itself offers a hosted search solution to third parties, or when the cost structure of a managed service tips the scale, for example through cheaper OpenSearch offerings from cloud providers. For pure internal use without resale, the migration effort often outweighs the actual benefit, especially if the existing cluster runs stably and no acute license conflicts exist.

# Typical migration path: snapshot on the source, restore on the target
# 1. Register a shared S3 repository readable by both clusters
# 2. Snapshot indices on the source cluster
curl -s -X PUT "https://source-cluster:9200/_snapshot/shared_repo/migration-2026-07-24" \
  -u elastic:changeme

# 3. Restore into the target cluster from the same repository
curl -s -X POST "https://target-cluster:9200/_snapshot/shared_repo/migration-2026-07-24/_restore" \
  -u admin:changeme

# 4. Validate document counts and sample queries before cutover
curl -s "https://target-cluster:9200/_cat/count/products?v" -u admin:changeme

9. Decision criteria for new projects

For a completely new project without existing baggage, the decision is easier, since no migration effort applies. For projects where an uncontested, permissive open source license is a hard requirement, there is a strong case for OpenSearch with its consistent Apache 2.0 licensing. For projects where the most advanced ML and vector search features tip the scale, or where the team already has extensive Elastic Stack know-how, there is a strong case for Elasticsearch despite the more complex license situation.

A practical test before the final decision: run both systems in parallel in a test environment with a realistic subset of the data and the actually required queries, and compare performance, resource consumption, and the maturity of the specific special functions needed directly. This practical evaluation often provides more reliable decision grounds than a purely theoretical feature list, because differences in the detailed behavior of aggregations, relevance scoring, or cluster stability only show up in real operation.

10. Summary

The 2021 fork turned a shared code base into two independent projects: Elasticsearch with dual, or by now triple, licensing under the control of Elastic N.V., and OpenSearch under a consistent Apache 2.0 license and foundation governance. Both systems still share the Lucene foundation and similar core concepts, but have increasingly diverged in vector search, security feature scope, dashboard tools, and API details.

The right choice between Elasticsearch and OpenSearch depends less on a blanket technical superiority than on concrete requirements: license restrictions relevant to your own business model, the need for specific ML features, existing team know-how, and the cost structure of the preferred cloud provider. A practical evaluation with real data and queries remains the most reliable path to a well founded decision.

11. FAQ: Elasticsearch vs. OpenSearch