Search · Updated 2026-06-11

OpenSearch vs Elasticsearch

Elasticsearch ships search innovation faster — ES|QL, the vector and semantic-search work, the integration catalogue — and the AGPL option ended the "not open source" era. OpenSearch gives you the full stack, security features included, under Apache 2.0 and neutral governance, with AWS’s managed service behind it. Deep on AWS or strict about permissive licensing: OpenSearch. Search quality as a product differentiator: Elasticsearch.

OpenSearch
The Apache-2.0 fork, now under the Linux Foundation.
Since
2021
By
OpenSearch Software Foundation (originally AWS)
License
Apache 2.0
opensearch.org ↗
Elasticsearch
The original Lucene-based search and analytics engine.
Since
2010
By
Elastic N.V.
License
AGPLv3 / ELv2 / SSPLv1
www.elastic.co/elasticsearch ↗

Both descend from the same codebase: when Elastic relicensed Elasticsearch in early 2021, AWS forked version 7.10 and called it OpenSearch. Five years of independent development later, the Elasticsearch vs OpenSearch choice is no longer "same thing, different license" — the APIs have drifted, the feature sets have diverged, and both projects changed their governance story along the way.

Quick takes

If you're…

  • You run on AWS and want the path of least resistance OpenSearch Amazon OpenSearch Service is the native managed offering, wired into CloudWatch, Firehose, and IAM.
  • Search relevance is your product (e-commerce, discovery) Elasticsearch Elastic’s relevance tooling — hybrid retrieval, semantic_text, reranking — moves faster.
  • Legal requires permissive open source across the stack OpenSearch Apache 2.0 under the OpenSearch Software Foundation, no copyleft, no vendor licenses.
  • You want SIEM/security analytics without per-feature pricing OpenSearch Security analytics, alerting, and anomaly detection ship free in the distribution.
  • Your team lives in Kibana and the Elastic agent ecosystem Elasticsearch OpenSearch Dashboards forked Kibana 7.10 and the muscle memory transfers only partially.
  • You need ES|QL-style piped queries for investigations Elasticsearch ES|QL is Elasticsearch-only; OpenSearch’s PPL is similar in spirit, different in syntax and depth.
  • You are choosing a vector store for RAG on AWS infrastructure OpenSearch OpenSearch k-NN (Faiss/Lucene engines) is mature and is what Bedrock knowledge bases use underneath.
  • You want commercial support from the people who write the engine Elasticsearch Elastic sells exactly that; OpenSearch support comes from AWS or third parties.
Decision wizard

A few questions, a verdict.

Q1

Where is your infrastructure?

Q2

What is the workload?

Q3

Licensing posture?

Q4

Who do you want on the other end of support?

At a glance

The scorecard.

Dimension
OpenSearch
Elasticsearch
Edge
Apache 2.0, LF foundation
AGPL option, vendor-held
OpenSearch
ES 7.10 ancestor + own path
Own path, no cross-upgrade
tie
Strong analytics suite
Faster search-core innovation
Elasticsearch
Whole stack, no tiers
Generous free tier + paid line
OpenSearch
Forked clients, 7.10-era compat
Product-check locks clients in
depends
AWS-native + independents
Elastic Cloud, multi-cloud
depends
Improving; fewer neutral numbers
Claims a lead; vendor-measured
depends
Growing, AWS-anchored
The incumbent ecosystem
Elasticsearch
In depth

Dimension by dimension.

core

License and governance

edge: OpenSearch
OpenSearch

Apache 2.0, full stop, for the engine, Dashboards, and the plugins. Governance moved from AWS to the OpenSearch Software Foundation under the Linux Foundation in September 2024, with SAP, Uber, Aiven, and Canonical alongside AWS. The neutrality is structural now, not promised.

Elasticsearch

Triple-licensed: AGPLv3 (added August 2024, OSI-approved), Elastic License 2.0, or SSPLv1. Open source again in the strict sense, but AGPL copyleft matters if you modify and serve it, and the trademark and roadmap remain one company’s.

core

Shared lineage, drifting APIs

tie
OpenSearch

Forked from Elasticsearch 7.10.2 and Kibana 7.10.2. The 7.x-era REST APIs, query DSL, and index concepts still feel identical. Everything added since — new APIs, settings, index features — is OpenSearch’s own and Elastic-incompatible.

Elasticsearch

Continued through 8.x and 9.x with its own breaking changes, new index formats, and features. There is no supported migration in either direction beyond the 7.10 ancestor: moving means reindexing, not upgrading.

features

Feature pace since the fork

edge: Elasticsearch
OpenSearch

Steady, with strengths in the analytics suite: security analytics, anomaly detection, index management, PPL query language, and serious k-NN work (Faiss and Lucene engines, GPU-accelerated index builds in the 3.x line). The cadence is real but the search-core innovation trails.

Elasticsearch

The faster shipper on the search core: ES|QL as a new query language, dense-vector improvements with int8/binary quantisation, semantic_text for managed embedding pipelines, retrievers for hybrid ranking, and the stateless serverless re-architecture. Elastic’s R&D depth on Lucene itself still shows.

features

What ships free

edge: OpenSearch
OpenSearch

Everything in the distribution: fine-grained security, SIEM-style security analytics, alerting, anomaly detection, cross-cluster replication, snapshots — all Apache 2.0. The project has no paid tier to protect, which shapes what lands in the box.

Elasticsearch

The free tier (Basic) is generous — security, vectors, much of the platform — but features like machine learning, some alerting connectors, and advanced tiers sit behind paid subscriptions. The line moves between releases; check it for the features you need.

ecosystem

Clients and library compatibility

depends
OpenSearch

Maintains forked clients (opensearch-py, opensearch-java, and so on) plus language-level compatibility with 7.10-era Elastic clients. Tooling that hardcodes Elastic version checks — some Beats versions, newer Logstash outputs — needs the OpenSearch outputs or Data Prepper instead.

Elasticsearch

Official Elastic clients from the 7.13/7.14 era onward perform a product check and refuse to connect to non-Elastic servers — the classic gotcha that breaks "drop-in" assumptions in both directions. Within its own ecosystem, client quality and codegen are excellent.

ecosystem

Managed offerings

depends
OpenSearch

Amazon OpenSearch Service (including serverless) is the flagship, deeply wired into the AWS fabric; Aiven, Instaclustr, DigitalOcean, and Oracle run it too. If your data already flows through AWS, the integration gravity is strong.

Elasticsearch

Elastic Cloud runs on AWS, GCP, and Azure, sells through the marketplaces, and gets new features first — including the serverless architecture. First-party only, but genuinely multi-cloud.

core

Performance claims

depends
OpenSearch

Has closed real gaps since the fork — concurrent segment search, k-NN improvements, faster aggregations — and publishes its own OpenSearch Benchmark suite. Independent third-party numbers are scarce.

Elasticsearch

Elastic publishes benchmarks claiming multi-x advantages over OpenSearch; OpenSearch contests the methodology. Both vendors benchmark their best case with their own tools (Rally vs OpenSearch Benchmark). Treat every number here as marketing until you run your own workload.

ecosystem

Ecosystem weight

edge: Elasticsearch
OpenSearch

Growing — 200+ maintainers, foundation members shipping in production (Uber, SAP), and the AWS integration surface. But the long tail of tutorials, plugins, certified connectors, and hireable experience still mostly says "Elasticsearch".

Elasticsearch

Fifteen years of accumulated ecosystem: agents and Beats, hundreds of integrations, books, courses, and the largest pool of operational lore in search. When something breaks at 3 a.m., the searchable answer base is unmatched.

History

The fork, and the licensing whiplash since.

Four dates explain most of the confusion in this comparison.

January 2021: Elastic relicensed Elasticsearch and Kibana from Apache 2.0 to SSPL/Elastic License with version 7.11, aimed squarely at AWS selling managed Elasticsearch. April 2021: AWS responded by forking the last Apache-2.0 release, 7.10.2, as OpenSearch. August 2024: Elastic added AGPLv3 as a third license option — Elasticsearch became OSI-approved open source again. September 2024: AWS transferred OpenSearch to the Linux Foundation, creating the OpenSearch Software Foundation and removing the "it’s just AWS’s fork" objection.

Both projects, in other words, fixed their original weakness. Elasticsearch is no longer proprietary-ish; OpenSearch is no longer single-vendor. What neither fixed is the split itself: indices, plugins, and clients stopped being interchangeable at 7.10, and five years of independent releases have made the gap permanent. Anyone promising you a trivial migration between them in either direction is describing 2021.

Practical consequence: treat them as two products that share ancestry and a query DSL dialect, the way MariaDB and MySQL share one. Choose on governance, cloud alignment, and which feature set maps to your workload — not on the assumption that you can switch later with a config change.

When to pick neither

A different shape of problem.

  • Under ~10M documents and you already run Postgres
  • Typesense / Meilisearch
    Product search with instant results and far simpler ops
  • Apache Solr
    The other Lucene veteran; strong in legacy enterprise search
  • Quickwit
    Log search on object storage at a fraction of the cluster cost
  • Log analytics where aggregation matters more than relevance
  • Pure vector retrieval without a search cluster
Situational picks

For specific cases.

Log analytics and SIEM on AWS infrastructure

OpenSearch

OpenSearch Service plus free security analytics, fed by Firehose and CloudWatch. The integration gravity and the pricing both point the same way.

E-commerce or content search where relevance moves revenue

Elasticsearch

Hybrid retrieval, semantic_text, reranking, ES|QL — the relevance toolchain is deeper and improving faster.

Open-source-only policy, self-hosted

OpenSearch

Apache 2.0 across engine, dashboards, and security features, governed by a foundation. No license lawyer required.

Established Elastic stack, wondering whether to jump

Elasticsearch

The AGPL option removed the main reason teams fled in 2021. A migration means reindexing, retooling dashboards, and retraining — pay that only for a concrete win.

Vector search backing a RAG feature on AWS

OpenSearch

OpenSearch k-NN is mature, Bedrock-integrated, and serverless if you want it. Elastic’s vector work is excellent too — this pick is about platform fit.

Mostly log search, cost is the complaint

Quickwit or ClickHouse

If you never use relevance scoring, a search cluster is an expensive way to grep. Object-storage-native log search or a columnar store cuts the bill structurally.

Sources

Primary material.

Found this useful?