In early 2024, a fintech team running a self-hosted Elasticsearch 7.10 cluster for transaction search and fraud detection got a harsh reminder about how much licensing decisions affect infrastructure planning. Elastic's January 2021 shift from Apache 2.0 to the Server Side Public License (SSPL) and Elastic License 2.0 had been easy to ignore while still on 7.10 — but as security vulnerabilities accumulated and performance gaps widened, upgrading became unavoidable. The team faced a concrete choice: pay for Elastic's commercial license to reach 8.x, or migrate to OpenSearch 2.x, the Apache 2.0-licensed fork AWS released in April 2021. They had six weeks to decide, with a production cluster indexing 40,000 documents per minute. This post walks through the decision framework they used — and what matters most for teams making the same call in 2026.
- Elastic changed its license from Apache 2.0 to SSPL + Elastic License 2.0 in January 2021 (version 7.11+); AWS forked Elasticsearch 7.10.2 and released OpenSearch 1.0 in July 2021.
- OpenSearch 2.x and Elasticsearch 8.x are no longer API-compatible — client libraries, index lifecycle APIs, and some query DSL features have diverged.
- OpenSearch ships full security (RBAC, field-level security, audit logging, TLS) for free; Elasticsearch requires a Gold or Platinum license for equivalent features.
- Both support HNSW-based vector search and competitive ML features, but through different plugin architectures and APIs.
- Elastic added an AGPL license option in August 2024, reducing some open-source concerns — but the Elastic License 2.0 still prohibits building competing managed services.
- For AWS-native teams or open-source licensing requirements, OpenSearch is the default choice; for teams heavily invested in Elastic's ML ecosystem (ELSER, Elastic AI Assistant), Elasticsearch 8.x is harder to leave.
The Fork: What Happened and Why It Matters
On January 21, 2021, Elastic announced that all future versions of Elasticsearch and Kibana — starting with 7.11 — would be released under the SSPL (Server Side Public License) and Elastic License 2.0, replacing the Apache 2.0 license that had made Elasticsearch one of the most widely deployed search engines in the world. The SSPL, written by MongoDB, requires any provider offering the software as a service to open-source their entire service stack — a condition that is effectively impossible for most commercial cloud providers to meet.
AWS, which had been offering Amazon Elasticsearch Service (and reselling Elasticsearch while contributing upstream), responded by forking Elasticsearch at version 7.10.2 — the last Apache 2.0 release — and creating the OpenSearch project. OpenSearch 1.0 shipped in July 2021 under Apache 2.0. By 2022, AWS had renamed Amazon Elasticsearch Service to Amazon OpenSearch Service and was steering new customers toward OpenSearch.
Five years later, the two projects have diverged substantially. OpenSearch 2.x has introduced its own plugin ecosystem, dashboard system (OpenSearch Dashboards, forked from Kibana), and ML framework. Elasticsearch 8.x has moved aggressively into AI-native search with ELSER (Elastic Learned Sparse EncodeR) and a tightly integrated vector search story. These are no longer interchangeable products — they are competing search platforms with a shared history.
Version Compatibility and API Differences
The most immediate operational concern for teams migrating or choosing between the two is client and API compatibility. Elasticsearch 8.x introduced breaking changes that also affect anyone trying to use Elasticsearch clients against an OpenSearch cluster — and vice versa.
| Area | OpenSearch 2.x | Elasticsearch 8.x |
|---|---|---|
| Official Java client | opensearch-java (separate artifact) | elasticsearch-java |
| Official Python client | opensearch-py | elasticsearch-py |
| Official Node.js client | @opensearch-project/opensearch | @elastic/elasticsearch |
| REST API compatibility header | Supports X-Elastic-Product compat header for some legacy tools |
Requires header; strict product check |
| Query DSL core | Mostly compatible with pre-8.x Elasticsearch | Largely backward-compatible with 7.x DSL |
| Aggregations | Has diverged; some new agg types not mirrored | Frequent new aggregation types in 8.x releases |
| Index templates | Composable index templates (aligned with 7.8+) | Composable index templates |
| Type removal | Types removed (aligned with ES 8.x approach) | Types fully removed in 8.0 |
Applications targeting Elasticsearch 7.x will generally work against OpenSearch 2.x with minimal changes — mostly client library swaps and namespace updates. Applications built for Elasticsearch 8.x will require more substantial rework to run against OpenSearch due to product-check headers, client API surface differences, and feature gaps.
Feature Comparison
| Feature | OpenSearch 2.x | Elasticsearch 8.x |
|---|---|---|
| License | Apache 2.0 | Elastic License 2.0 / AGPL (since Aug 2024) |
| Security — TLS | Free, built-in via Security plugin | Mandatory since 8.0, free in Basic tier |
| Security — RBAC | Free, built-in (roles, users, permissions) | Requires Gold license ($) |
| Field-level security | Free, built-in | Requires Platinum license ($$$) |
| Audit logging | Free, built-in | Requires Gold license ($) |
| Vector search | k-NN plugin (HNSW via faiss, nmslib, lucene engines) | Native dense_vector field, HNSW since 8.0 |
| ML / AI | ML Commons plugin, neural search, remote model inference | ELSER (Elastic Learned Sparse EncodeR), Elastic AI Assistant |
| Semantic search | Neural search plugin, sparse encoding via ML Commons | ELSER (native sparse retrieval), semantic_text field type |
| Dashboards / UI | OpenSearch Dashboards (Kibana fork) | Kibana |
| Index lifecycle | Index State Management (ISM) | Index Lifecycle Management (ILM) |
| Cross-cluster replication | Free, built-in (CCR plugin) | Requires Platinum license ($$$) |
| Alerting | Free, Alerting plugin (built-in monitors, destinations) | Alerting in Basic tier (Watcher for advanced scenarios, paid) |
| Observability | Observability plugin, Trace Analytics | Elastic Observability (APM, logs, metrics) — some features paid |
| SQL support | SQL plugin (PPL — Piped Processing Language) | Elasticsearch SQL (EQL for event queries) |
| Snapshot / restore | S3, GCS, Azure repositories; incremental snapshots | S3, GCS, Azure repositories; searchable snapshots (paid) |
Licensing Deep Dive
Licensing is where the two projects differ most consequentially, and where teams most often get burned by assumptions made at evaluation time.
OpenSearch is licensed under Apache 2.0. This is a permissive, OSI-approved open-source license. You can fork it, embed it in commercial products, offer it as a managed service, and distribute modified versions without any obligation to open-source your changes or pay royalties. This is why AWS, Aiven, and others run OpenSearch as a managed service without legal complications.
Elasticsearch from version 7.11 onward is dual-licensed under the Elastic License 2.0 and the Server Side Public License (SSPL). The Elastic License 2.0 explicitly prohibits using the software to provide a managed service or SaaS offering that competes with Elastic's own products. In August 2024, Elastic added a third option: the GNU Affero General Public License (AGPL v3). AGPL requires that you open-source any modifications you make if you distribute the software or run it as a network service — which is more feasible for internal deployments but still restricts commercial service providers.
Performance Comparison
For most CRUD-heavy search workloads — full-text search, filtered queries, aggregations — OpenSearch 2.x and Elasticsearch 8.x perform comparably at equivalent hardware. Both are built on Apache Lucene and share the same underlying segment-based storage model, segment merging behavior, and inverted index architecture. Tuning levers (refresh intervals, merge policies, shard allocation) are nearly identical.
| Workload | OpenSearch 2.x | Elasticsearch 8.x |
|---|---|---|
| Full-text search throughput | Comparable (Lucene-based) | Comparable (Lucene-based) |
| Indexing throughput | Comparable; bulk API behavior identical | Comparable; logsdb index mode offers compression gains |
| Vector search (ANN) | k-NN plugin: HNSW via faiss or lucene engine | Native HNSW via Lucene; slightly lower latency on benchmarks |
| Sparse / semantic retrieval | Neural search with external model or ML Commons | ELSER (first-party sparse model, highly optimized) |
| Disk usage | Standard Lucene compression | logsdb mode: significant compression for log data (up to 65% reduction) |
The meaningful performance gap in 2026 is in AI-native retrieval. Elastic's ELSER model, trained on Elastic's own infrastructure and optimized for their vector storage layer, consistently outperforms external model integrations in OpenSearch on semantic search recall benchmarks. If semantic search quality is your primary metric, Elasticsearch 8.x has a measurable advantage today.
Cloud and Managed Options
AWS OpenSearch Service is the dominant managed OpenSearch offering. It supports both OpenSearch 2.x domains and legacy Elasticsearch 7.x domains (for teams that have not yet migrated). It integrates natively with IAM, VPC, CloudWatch, and KMS. OpenSearch Serverless, launched in 2023, removes capacity planning entirely for variable workloads.
Elastic Cloud is the managed Elasticsearch offering from Elastic. It runs on AWS, GCP, and Azure. It includes the full Elastic stack (Elasticsearch, Kibana, APM, Fleet) and is the only managed option that supports ELSER and the Elastic AI Assistant natively. Pricing is consumption-based and includes the cost of the commercial license — there is no self-hosted-with-Elastic-Cloud hybrid.
Other managed options include Aiven for OpenSearch (multi-cloud, Apache 2.0), Bonsai (Elasticsearch, smaller clusters), and self-hosted deployments on Kubernetes via the Elastic Operator (ECK) or the OpenSearch Kubernetes Operator.
Migration Between OpenSearch and Elasticsearch
Moving data between OpenSearch and Elasticsearch is achievable but requires planning. The two systems can read each other's Lucene segment files only at compatible versions — in practice, snapshot/restore is the safest path.
The general migration process for moving from Elasticsearch 7.x to OpenSearch 2.x involves taking a snapshot of the source cluster to an S3-compatible repository, registering that repository in the target OpenSearch cluster, and restoring the indices. Index settings and mappings are preserved; aliases and lifecycle policies must be recreated manually using OpenSearch's ISM syntax rather than Elasticsearch's ILM syntax.
Application-layer changes are the more labor-intensive part: every client library call must be updated to use the OpenSearch client packages, authentication configuration changes (OpenSearch Security uses a different user/role model than Elasticsearch's native realm), and any Kibana dashboards must be exported and re-imported into OpenSearch Dashboards (the JSON formats are mostly compatible but diverge in visualization definitions added after the fork).
Which to Choose in 2026?
The choice between OpenSearch and Elasticsearch in 2026 comes down to four factors: licensing requirements, ML/AI feature needs, cloud platform alignment, and total cost of ownership for security features.
| Scenario | Recommended Choice | Reason |
|---|---|---|
| Building a managed search service or SaaS product | OpenSearch | Apache 2.0 — no license restrictions on service offerings |
| AWS-native infrastructure | OpenSearch | Managed OpenSearch Service, IAM integration, native S3 snapshots |
| Self-hosted with full security features, no budget for commercial license | OpenSearch | RBAC, FLS, CCR, alerting all free in OpenSearch Security plugin |
| AI-native semantic search with minimal ML infrastructure | Elasticsearch | ELSER provides best-in-class sparse retrieval without external model hosting |
| Elastic Stack ecosystem (APM, Fleet, Security SIEM) | Elasticsearch | Deep integration across Elastic products; Kibana + APM are tightly coupled |
| Migrating from Elasticsearch 7.x with minimal changes | OpenSearch | API surface is closer to 7.x; client migration is less disruptive than upgrading to 8.x |
| Regulated industry requiring open-source auditability | OpenSearch | Apache 2.0 satisfies most open-source requirements; SSPL/EL2 does not |
| Existing Elastic Cloud investment with active support contract | Elasticsearch | Switching cost likely exceeds benefit unless licensing or cost is acute pain point |
For the fintech team from the introduction: they chose OpenSearch. Their primary drivers were RBAC and field-level security for PII compliance (free in OpenSearch, $40K+ annually in Elastic Gold for their cluster size) and AWS-native infrastructure that made OpenSearch Service the natural fit. The migration took four weeks, the bulk of which was updating client libraries and recreating lifecycle policies in ISM syntax. Indexing performance and search latency were indistinguishable from their previous Elasticsearch 7.10 setup.
- Elastic's January 2021 license change from Apache 2.0 to SSPL/EL2 is the root cause of the fork and remains the most important differentiator for commercial and SaaS use cases in 2026.
- OpenSearch 2.x and Elasticsearch 8.x are no longer API-compatible — treat them as distinct products that share Lucene internals, not as interchangeable alternatives.
- OpenSearch ships enterprise security features (RBAC, FLS, CCR, audit logging) for free; Elasticsearch requires Gold or Platinum licenses for the same capabilities on self-hosted deployments.
- Elasticsearch 8.x has a meaningful AI/ML advantage with ELSER for semantic search; OpenSearch's ML Commons and neural search are competitive but require more external infrastructure.
- Migrating from Elasticsearch 7.x to OpenSearch 2.x is straightforward via snapshot/restore; migrating from Elasticsearch 8.x to OpenSearch requires re-indexing from a live cluster.
- Elastic added AGPL as a third license option in August 2024, but the Elastic License 2.0 still applies and still prohibits competitive managed services — verify which license applies to your specific use case before committing.
Working with JusDB on OpenSearch and Elasticsearch
JusDB manages OpenSearch and Elasticsearch deployments for teams building search, observability, and analytics platforms. We handle cluster sizing, index lifecycle management, security configuration, and performance tuning.
Explore JusDB OpenSearch Services → | Talk to a DBA
Related reading: