Elasticsearch and OpenSearch: revisit the fork before you pick one

Many teams still talk about “our Elastic cluster” when the cluster is actually Amazon OpenSearch Service, or about “OpenSearch” when half the code paths still use an old Elasticsearch client. That loose talk was harmless in 2021, when both engines were close to the same 7.10 code. It is risky now. The two projects have moved to different majors, ship different features on top of Lucene, and do not promise client compatibility with each other.

This post covers the history, the licence position in plain words, where the engines have diverged, what migration really involves, and a small drill to try before you commit. The facts come from Elastic, AWS, Linux Foundation and OpenSearch project pages, docs and release notes, checked on 5 October 2026. Nothing here is legal advice. Performance claims are labelled as the vendor’s or project’s own.

The short version

  • Elastic announced on 14 January 2021 that Elasticsearch and Kibana source code would move from Apache 2.0 to a choice of SSPL or the Elastic License, before the 7.11 release. Elastic’s own distribution stayed under the Elastic License.
  • AWS announced OpenSearch on 12 April 2021: OpenSearch derived from Elasticsearch 7.10.2 and OpenSearch Dashboards derived from Kibana 7.10.2, all under Apache License 2.0. OpenSearch 1.0 became generally available on 12 July 2021.
  • On 29 August 2024, Elastic added AGPLv3, an OSI approved licence, as a third option for the source code. The Elasticsearch repository today defaults to a triple licence (AGPLv3, SSPL 1.0, ELv2), with code under the x-pack folder covered only by ELv2.
  • The Linux Foundation announced the OpenSearch Software Foundation on 16 September 2024. AWS moved OpenSearch under it.
  • Both engines are on the Lucene 10 line now: Elasticsearch 9.0 runs on Lucene 10, and OpenSearch 3.0 upgraded to Lucene 10.1.0 with JDK 21 as the minimum runtime.
  • Current releases seen on 5 October 2026: Elasticsearch 9.5.4 (download page, release date 15 September 2026) with 8.19.22 on the 8.x line (23 September 2026), and OpenSearch 3.9.0 (released 29 September 2026).
  • The OpenSearch docs state that for OpenSearch 2.0 and later, no Elasticsearch clients are fully compatible with OpenSearch. Treat them as two products with a shared ancestor, not two names for one engine.

How the split happened

Elasticsearch started as a project by Shay Banon, open sourced in 2010, with Elastic founded as a company in 2012. For most of its life the core was Apache 2.0, while Elastic built paid and free features under its own licence and bundled them into a default distribution.

The turning point came in early 2021. Elastic’s post of 14 January 2021 said the Apache 2.0 code in Elasticsearch and Kibana would become dual licensed under SSPL and the Elastic License, applied to maintained branches before 7.11. The stated reason was to stop cloud providers from offering the products as a service without contributing back. Elastic’s licensing FAQ adds that it no longer produces an Apache 2.0 distribution.

AWS replied on 21 January 2021 that it would create and maintain an Apache 2.0 fork of Elasticsearch and Kibana. It already had Open Distro for Elasticsearch, which added security, alerting, SQL and index state management on top of Elastic’s OSS builds. On 12 April 2021 AWS introduced OpenSearch, folded Open Distro into it, and said Amazon Elasticsearch Service would be renamed Amazon OpenSearch Service. The first code was labelled alpha; OpenSearch 1.0 reached general availability in July 2021.

Two later events changed the picture again:

  • 29 August 2024: Elastic’s post “Elasticsearch Is Open Source. Again!” announced AGPL as an extra option alongside ELv2 and SSPL. The FAQ said the change was expected before 8.16 was generally available.
  • 16 September 2024: the Linux Foundation launched the OpenSearch Software Foundation, with AWS, SAP and Uber as premier members, and the OpenSearch Project overseen by a technical steering committee.

So the old summary “one is open source and one is not” no longer fits. Both now offer an OSI approved licence for source code. The difference has moved to which licence, which governance model and which distribution you actually run.

Licence in plain words

Elasticsearch. You can take the source under AGPLv3, SSPL 1.0 or ELv2, depending on the file header. Elastic’s FAQ says its releases (the default distribution you download) continue under the Elastic License 2.0. ELv2 has three short limits. The one most teams care about: you may not provide the software to third parties as a hosted or managed service that gives users access to a substantial set of its features. You also may not bypass licence key functionality or remove licensing notices. Elastic’s client libraries stay under Apache 2.0.

OpenSearch. The OpenSearch repository is under Apache License 2.0, as announced in 2021, and the AWS post says no contributor licence agreement is needed to contribute.

What this means for a working team:

  • Running either engine inside your own product or platform is usually fine. Elastic’s FAQ says you may use Elasticsearch inside your SaaS or self-managed application, within the ELv2 limits.
  • Offering search itself as a managed service to customers is where the licences differ in a real way. Read ELv2, SSPL and AGPLv3 with your legal team before you do that on Elasticsearch.
  • AGPLv3 is a copyleft licence. Elastic’s FAQ sums it up as requiring that modifications and derivative works be made available under the same licence. “OSI approved” does not mean “no obligations”.
  • Elastic’s default distribution carries both free and paid features under ELv2, and ELv2 forbids bypassing the licence key. List the features you depend on and check which subscription tier includes them.

Where the engines have diverged

Release lines and Lucene

OpenSearch uses semantic versioning. Its release page says breaking changes land only in major versions, majors tend to follow Lucene major releases, and the project aims for a minor release about every eight weeks. OpenSearch 2.0 went GA on 26 May 2022 and 3.0 on 6 May 2025. The 2.19 line is in maintenance until the GA of 4.0.

Elasticsearch moved to 9.0 in April 2025 on Lucene 10. Elastic’s breaking changes page says a move to 9.x from an earlier version must first go through the last 8.x release.

Both sides keep tracking Lucene closely. The Elasticsearch 9.5.2 notes list an upgrade to Lucene 10.5.1. The OpenSearch 3.8 release notes record the k-NN plugin moving to Lucene 10.5.0. Same library underneath does not mean the same index codecs, mappings or query features on top.

Query languages and field types

Each side has added its own layer:

  • Elasticsearch has ES|QL, its own piped query language.
  • OpenSearch has SQL and PPL (Piped Processing Language), which processes data step by step through pipes. SQL was one of the Open Distro features AWS carried into OpenSearch.
  • Elasticsearch uses dense_vector for vectors and flattened for object-like fields. OpenSearch uses knn_vector and flat_object. The OpenSearch Migration Assistant has documented transforms for both, and it warns that application queries may still need changes after the mapping moves.
  • Index lifecycle is ILM in Elasticsearch and ISM in OpenSearch. The Migration Assistant lists these policies as “manually recreate on target”.

Dashboards and UI

OpenSearch Dashboards started from Kibana 7.10.2. Kibana has since moved through 8.x and 9.x on its own path. Saved objects do not travel by themselves: the Migration Assistant table lists Kibana and Dashboards objects as export and import through the Dashboards UI, and security configuration, ingest pipelines and cluster settings as things you set up again on the target.

Vector and performance claims

Both projects publish strong numbers. Elastic’s 9.0 search blog says its Better Binary Quantization delivers up to 5x faster queries and 3.9x higher throughput than OpenSearch FAISS. That is Elastic’s own claim, against its competitor. The OpenSearch 3.0 announcement reports its own gains, such as up to 30x better p90 cold start latency for derived source on the Lucene engine. That is the project’s own claim. Neither replaces a test on your data, your hardware and your recall target.

Compatibility and migration

Clients

This is where many migrations break first. From version 7.14, several Elastic-maintained clients added a product check. The Python client docs describe it: before the first API call the client checks the X-Elastic-Product: Elasticsearch header or the info API, and raises UnsupportedProductError if the server is not a supported Elasticsearch. The OpenSearch project responded in August 2021 by forking the clients (opensearch-py, opensearch-java, opensearch-js, opensearch-go and others) from the last versions before that check.

The OpenSearch client docs now say two things clearly. Legacy Elasticsearch clients around 7.13 may work with OpenSearch 1.x. For OpenSearch 2.0 and later, no Elasticsearch client is fully compatible, and OpenSearch clients are recommended. If your code base still imports an Elasticsearch client while pointing at OpenSearch, put that on the risk list today.

Data and metadata

Snapshots are not a universal bridge. OpenSearch says its snapshots are forward compatible by only one major version. Elastic’s own snapshot docs say an index must be compatible with the target cluster version, and Kibana applies extra checks of its own on restore.

For moving data into OpenSearch, the project’s Migration Assistant (now a Kubernetes-based tool) offers:

  • Backfill through Reindex-from-Snapshot, which reads shard data from a snapshot in object storage instead of querying the live source.
  • Capture and Replay for a zero-downtime path, recording live writes through a proxy, buffering them in Kafka and replaying them on the target.
  • Automatic migration of index settings, mappings, templates and aliases.

Read the limits before you plan. The supported path matrix checked on 5 October 2026 lists Elasticsearch sources from 1.x to 8.x; Elasticsearch 9.x is not listed. Elasticsearch 8.x is supported “with compatibility support for post-fork features”, with a note that some 8.x features may have no OpenSearch equivalent. Shards up to 80 GiB are supported by default, and indexes using the zstd or zstd_no_dict codecs (OpenSearch 2.9+) must be reindexed first.

For smaller jobs, OpenSearch also supports reindex from a remote cluster. The remote host has to be listed in reindex.remote.allowlist in opensearch.yml, and failed remote requests are retried with exponential backoff.

Going the other way, from OpenSearch to Elasticsearch, has no matching assistant in the sources checked for this post. Plan it as a fresh index load with your own pipeline and test it.

Operations: what changes on day two

  • Runtime: OpenSearch 3.0 needs JDK 21 as the minimum. It also replaced the Java Security Manager with a Java agent for plugin sandboxing, because newer JDKs disabled the Security Manager. Plugin authors and teams with custom plugins should note this.
  • Security: OpenSearch uses its Security plugin, with its own roles and a .opendistro_security config index. Elasticsearch security is the x-pack security plugin, in the ELv2-only part of the repository. The Migration Assistant lists security configuration as something to set up separately on the target.
  • Upgrades: on Elasticsearch, a move to 9.x goes through the last 8.x release first. On OpenSearch, minors within a major are meant to be compatible under semver, and OpenSearch snapshots move forward by only one major at a time.
  • Support lines: OpenSearch keeps the previous major in maintenance for bug and security fixes. Elastic keeps shipping 8.19.x patches alongside 9.5.x. Check the end dates that matter to your audit team on each vendor’s page.
  • Managed services: if you are on a cloud service, the engine version and plugin set are chosen by the provider. Confirm the exact version string with GET / before you trust any compatibility table.

A decision guide

Answer these in one meeting and write the answers down:

  1. Do you run search inside your own product, or do you offer search as a service to others? The second case needs a licence review for Elasticsearch.
  2. Is Apache 2.0 a hard requirement for your organisation, or is AGPLv3, SSPL or ELv2 acceptable after review?
  3. Which client libraries and versions are in your code today, and do any of them perform a product check?
  4. Do you depend on ES|QL, Kibana 8.x or 9.x features, or Elastic security and observability apps? Or on SQL, PPL, ISM and OpenSearch plugins?
  5. Do you use dense_vector, flattened, zstd codecs, data streams or ingest pipelines that need translation or manual rebuild?
  6. Are you on Elasticsearch 9.x? If yes, check the Migration Assistant matrix again before planning an OpenSearch move.
  7. Who gives you support: Elastic under a subscription, a cloud provider, or your own team with the community?
  8. Can you run both engines side by side for a few weeks, with real queries, before cutover?

If most of your answers point to “inside our product, no service resale, Elastic features in daily use”, staying on Elasticsearch is reasonable. If they point to “Apache 2.0 required, AWS managed service, OpenSearch clients already in use”, OpenSearch is the natural home. A mixed answer means you need the drill below.

Practice drill: compare one index on both engines

Unlearn one idea first: “same REST paths means same engine”. Then, on a laptop or sandbox VM:

  1. Start one single-node Elasticsearch 9.5.4 and one single-node OpenSearch 3.9.0, following each project’s Docker install page. Map OpenSearch to host port 9201 so both can run together. Keep security on, as both guides do.
  2. Create the same index with plain text, keyword and date fields on both. Load the same 10,000 sample documents with the bulk API.
  3. Add one flattened field and one dense_vector field to the Elasticsearch mapping and try the same mapping on OpenSearch. Record the errors and the OpenSearch equivalent (flat_object, knn_vector).
  4. Run 20 real queries from your logs on both. Compare hit counts and the top 10 document IDs. Do not expect identical scores; do expect to explain every difference.
  5. Point your current application client at each engine. If it is an Elastic client, watch for UnsupportedProductError on OpenSearch. Then try the matching OpenSearch client.
  6. On OpenSearch, add the Elasticsearch host to reindex.remote.allowlist in opensearch.yml, restart the node, and try a reindex from remote of the test index. Note what moves and what does not (templates, ILM, pipelines, dashboards).
  7. Write a one-page result: what broke, what needed translation, and how long the copy took on your hardware. Label every number as your own run.

Call the root endpoint on each and save the output:

curl --cacert http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200/
curl -k -u admin:$OPENSEARCH_INITIAL_ADMIN_PASSWORD https://localhost:9201/

OpenSearch reports "distribution" : "opensearch" inside version. Note what each returns; your code may branch on it.

The drill takes an afternoon. It will tell you more than any comparison table, including this post.

Sources

comments powered by Disqus

Releted Posts

Kafka and Redpanda: revisit the choice before you treat them as the same bus

Many teams say “we run Kafka” when they mean “our services talk to a Kafka-compatible broker”. That shortcut was useful when one open source broker dominated the protocol.

Read more

OpenTofu and Terraform: revisit the fork before you pick one

Many teams picked Terraform years ago and have not looked at the choice since. In August 2023 its licence changed and a fork appeared.

Read more

Redis, Valkey, and Dragonfly operations: persistence and failover

A cache becomes a database the day nobody can rebuild it. After that day, persistence and failover are not settings copied from a blog.

Read more