In 2021, Elastic changed Elasticsearch’s license from Apache 2.0 to SSPL and ELv2. AWS responded by forking the last Apache-licensed version into OpenSearch. What started as a licensing dispute has produced two actively developed, increasingly divergent search engines–each with its own ecosystem, managed service options, and feature trajectory.
Five years on, the “just pick whichever” advice doesn’t hold up. If you’re starting a new project or reevaluating your stack, the choice between them involves more than license preference. It affects your managed service options, your tooling ecosystem, and your long-term migration costs.
The Licensing Saga
Understanding the history matters because it shapes the ecosystem dynamics.
Elasticsearch was Apache 2.0 licensed from its inception. AWS built a managed Elasticsearch service, added proprietary features, and marketed it under the Elasticsearch name. Elastic argued this was exploiting their open source work without contributing back. In January 2021, Elastic re-licensed Elasticsearch under a dual SSPL/ELv2 license, effectively preventing cloud providers from offering it as a managed service without a commercial agreement.
AWS forked the last Apache 2.0 version (Elasticsearch 7.10.2) and launched OpenSearch. The fork maintained the Apache 2.0 license and began independent development under the Linux Foundation’s governance.
The story didn’t end there. In August 2024, Elastic re-licensed Elasticsearch again, this time adding AGPL as an option alongside SSPL and ELv2. AGPL is a recognized open source license by the OSI, which technically returned Elasticsearch to “open source” status. But the practical implications depend on your use case. AGPL’s copyleft requirements mean that if you modify Elasticsearch and offer it as a service, you must release your modifications. For internal use, AGPL is permissive enough. For building products on top of Elasticsearch, the AGPL obligations require careful legal review.
OpenSearch remains Apache 2.0–no copyleft, no restrictions on how you use, modify, or distribute it. For organizations where licensing certainty matters, that distinction is meaningful.
Current State of the Split
Both projects are under active development and have diverged significantly since the fork. Elasticsearch moved to version 8.x with breaking changes to its security model, API structure, and default behaviors. OpenSearch followed its own versioning, now at 2.x, charting a separate course.
The core Lucene-based search engine underneath both projects still shares DNA. Query DSL syntax is largely compatible. Most applications that talk to Elasticsearch 7.x can communicate with OpenSearch with minor adjustments. But the gap widens with each release. New features in Elasticsearch don’t appear in OpenSearch and vice versa. Plugins, clients, and integrations increasingly target one or the other rather than both.
Migration between the two remains feasible for straightforward deployments. Index formats are compatible for data created on the shared Elasticsearch 7.10 base. But the longer you invest in features specific to either platform, the harder switching becomes.
Where Elasticsearch Leads
Feature Velocity
Elastic has the advantage of a focused commercial entity driving development. Features ship faster and with more polish. ES|QL, Elasticsearch’s piped query language introduced in 8.11, provides a SQL-like alternative to the Query DSL that simplifies ad-hoc analysis for operators who don’t want to learn nested JSON query syntax. Vector search and kNN capabilities have matured rapidly, with quantization options, hybrid scoring, and optimized HNSW implementations that OpenSearch is still catching up to.
Elasticsearch also moves faster on Lucene upgrades, often adopting the latest Lucene releases within weeks. This means performance improvements, bug fixes, and new index codec features reach Elasticsearch users sooner. OpenSearch tends to lag a version or two behind on Lucene integration, which occasionally means missing out on meaningful search quality and performance improvements.
ML and AI Integration
Elastic has invested heavily in machine learning. Trained model inference runs directly inside Elasticsearch nodes, enabling semantic search, NER, text classification, and ELSER (Elastic’s sparse retrieval model) without external dependencies. The Inference API provides a unified interface for connecting to third-party LLMs and embedding services. If AI-augmented search is central to your roadmap, Elasticsearch is further along.
The Elastic Stack
Kibana, Beats, Logstash, and Elastic Agent form a cohesive ecosystem. Kibana’s visualization capabilities, dashboard authoring, and alerting are more polished than OpenSearch Dashboards. The Elastic Agent provides a single binary for collecting logs, metrics, and security telemetry. Elastic’s SIEM and Endpoint Security products build on top of the same stack. If you want a unified observability and security platform, the Elastic Stack offers tighter integration than assembling equivalent pieces around OpenSearch.
Commercial Support
Elastic offers tiered subscriptions with SLAs, dedicated support engineers, and access to proprietary features like machine learning anomaly detection, searchable snapshots at the frozen tier, and cross-cluster replication. For enterprises that need contractual guarantees, this matters.
Where OpenSearch Leads
Licensing Clarity
Apache 2.0 is about as simple as software licensing gets. Use it however you want. Modify it. Build products on it. Offer it as a managed service. There are no copyleft obligations, no restrictions on commercial use, and no ambiguity about what you can and cannot do. Legal teams appreciate this.
AWS Integration
Amazon OpenSearch Service is a mature managed offering with deep AWS integration. VPC support, IAM-based access control, integration with CloudWatch, Lambda, Kinesis, and S3–if your infrastructure runs on AWS, OpenSearch plugs in with minimal friction. Infrastructure-as-code support through CloudFormation and Terraform is well-established, and the service integrates natively with AWS’s security and networking primitives.
The Serverless option deserves specific attention. It removes capacity planning entirely, scaling automatically based on workload and charging per-use. You don’t choose instance types, manage shards, or worry about cluster topology. For applications with unpredictable or bursty search traffic, this eliminates a significant operational burden. The trade-off is less control over performance tuning and higher per-query cost at sustained high throughput compared to provisioned clusters.
Community Governance
OpenSearch operates under the Linux Foundation with community-driven governance. Feature development, roadmap decisions, and release planning happen in the open. There’s no risk of a single company changing the license or restricting features behind a commercial tier. For organizations with policies around vendor lock-in or open source purity, this governance model provides assurance that Elastic’s structure cannot.
Growing Feature Independence
OpenSearch isn’t just maintaining a fork. It has developed its own features: Security Analytics, Anomaly Detection, Alerting, and Index Management were part of the Open Distro for Elasticsearch project before the fork and have continued to evolve. SQL and PPL (Piped Processing Language) query support gives alternatives to the Query DSL. The Notifications plugin provides a unified alerting framework. These features are all open source, included by default, with no commercial tier gating.
Cost Sensitivity
OpenSearch tends to be cheaper to run, and the difference compounds at scale. Amazon OpenSearch Service pricing is competitive with other managed database services on AWS, and the Serverless option can reduce costs for variable workloads significantly. Self-hosted OpenSearch has no license fees regardless of scale or feature usage–every feature ships in the open source distribution.
With Elasticsearch, the picture is more layered. The free tier covers basic search and analytics, but features like machine learning, advanced security, and searchable snapshots require a paid subscription. Elastic Cloud pricing at scale can be substantial, particularly for observability workloads that ingest large volumes of data. Teams running multi-terabyte clusters often find that the managed service cost becomes a line item worth scrutinizing.
API Compatibility
Applications built against Elasticsearch 7.x generally work with OpenSearch after adjusting client libraries and connection configuration. The core Query DSL, index operations, and bulk API remain compatible. Most REST API endpoints behave the same way.
The friction points are specific. Security configuration differs–OpenSearch uses its own security plugin rather than Elastic’s X-Pack security. Client libraries have diverged; OpenSearch publishes its own clients for Python, Java, Go, and other languages. Elasticsearch 8.x clients won’t work with OpenSearch without modification. Kibana plugins don’t run on OpenSearch Dashboards and vice versa.
For new projects, pick one and commit. For migrations, the effort depends on how deeply you’ve integrated with platform-specific features. A basic search application using standard queries and index operations can switch with a few days of work. An observability platform using Elastic APM, machine learning jobs, and custom Kibana plugins is a different story entirely.
One practical consideration: if you’re using Terraform or infrastructure-as-code, the provider configurations are entirely different. AWS provider resources manage OpenSearch Service, while the Elastic provider manages Elastic Cloud deployments. Swapping between them means rewriting your infrastructure definitions, not just your application code.
Managed Service Comparison
Elastic Cloud runs on AWS, Azure, and GCP. You get the full Elastic Stack with all commercial features included at the appropriate subscription tier. Autoscaling, cross-region replication, and searchable snapshots are available. Elastic manages upgrades and infrastructure. The deployment model is flexible–you can run clusters in multiple regions across different cloud providers from a single console. The trade-off is cost. Elastic Cloud pricing at scale is notably higher than self-managed or AWS-managed alternatives, and costs can escalate quickly as you add nodes, storage, or premium features.
Amazon OpenSearch Service runs exclusively on AWS. You get managed clusters with automated backups, in-place upgrades, fine-grained access control, and UltraWarm and cold storage tiers for cost-effective log retention. The Serverless option eliminates cluster management entirely. Pricing is based on instance hours and storage, which tends to be more predictable and lower than Elastic Cloud for equivalent workloads. The trade-off is that you’re locked into AWS, and some advanced features lag behind Elasticsearch.
There are also third-party options worth noting. Aiven offers managed OpenSearch across multiple cloud providers, giving you OpenSearch without the AWS lock-in. Bonsai and other smaller providers offer managed Elasticsearch. But the primary competition is between Elastic Cloud and Amazon OpenSearch Service, and most teams choose based on their existing cloud provider relationship.
If you’re multi-cloud or not on AWS, Elastic Cloud is the natural managed choice. If you’re AWS-native and cost-conscious, Amazon OpenSearch Service is hard to beat on value.
Use Case Alignment
Log Analytics and Observability
Both work well. Elastic has the more mature observability story with Elastic APM, unified Elastic Agent, and pre-built Kibana dashboards for common platforms. OpenSearch has Observability plugins with trace analytics and log correlation, and it integrates well with open source tools like Fluent Bit and Data Prepper. If you’re building an observability stack from scratch on AWS, OpenSearch is practical and cost-effective. If you want a turnkey solution with strong correlation across logs, metrics, and traces, the Elastic Stack is more polished.
Full-Text Search
The core search capabilities are nearly identical. Both use Lucene under the hood, support the same analyzers and tokenizers, and handle full-text search with comparable performance and relevance. For a product search engine, documentation site search, or content discovery feature, either will serve you well.
Where differences emerge is in the tooling around search. Elasticsearch’s Learning to Rank plugin and query rules engine provide more sophisticated relevance tuning. OpenSearch has its own search relevance plugin for comparing query results side by side. But for the vast majority of full-text search implementations, the choice comes down to surrounding infrastructure and operational preferences rather than search quality itself.
Vector and Semantic Search
Elasticsearch is ahead. ELSER, native model inference, and the Inference API provide a more complete solution for semantic search out of the box. OpenSearch supports kNN search and has added neural search plugins, but the developer experience and performance optimizations aren’t as mature. If vector search is a primary use case rather than a secondary feature, Elasticsearch gives you more to work with today.
Security Analytics (SIEM)
Elastic Security is a full-featured SIEM built on Elasticsearch, with detection rules, case management, endpoint protection, and a growing library of pre-built detections mapped to the MITRE ATT&CK framework. It competes directly with dedicated SIEM products like Splunk and Microsoft Sentinel.
OpenSearch Security Analytics provides detection and correlation capabilities but is less mature. It supports Sigma rules for detection and includes basic threat intelligence integration, but it lacks the depth of Elastic’s case management and endpoint response features. For a dedicated security analytics deployment, Elastic has a significant lead. For basic security log analysis alongside other workloads, OpenSearch’s built-in capabilities may be sufficient.
When to Choose Elasticsearch
- You need the latest search features, particularly around vector search, ML inference, and ES|QL
- You want the Elastic Stack ecosystem with Kibana, Beats, and Elastic Agent working as a unified platform
- Your infrastructure spans multiple cloud providers or runs outside AWS
- You’re building a security analytics or APM solution and want an integrated product rather than assembled components
- Commercial support with SLAs is a requirement
- Your team has existing Elasticsearch expertise and wants to stay on the canonical project
When to Choose OpenSearch
- You run on AWS and want tight integration with your existing infrastructure and IAM model
- Licensing simplicity matters–Apache 2.0 with no ambiguity or legal review required
- You want a capable search and analytics platform where every feature is included, no paid tiers
- Cost is a significant factor, especially for multi-terabyte clusters or high-ingest observability workloads
- You prefer community-governed open source with Linux Foundation backing and no single-vendor risk
- The Serverless option aligns with your operational model and you want to avoid cluster management entirely
The Bottom Line
Elasticsearch and OpenSearch are both solid, production-grade search and analytics platforms used by thousands of organizations. They share enough heritage that the core experience is similar, but they’ve diverged enough that the choice has real consequences for your team’s workflow, costs, and future flexibility.
Elasticsearch is the more feature-rich option, particularly for ML-augmented search, observability, and security. It moves faster and integrates more tightly with its own ecosystem. The trade-offs are cost, licensing complexity, and dependency on Elastic as a company.
OpenSearch is the pragmatic choice for AWS-centric teams that want a capable, truly open source search platform without licensing concerns or commercial tier restrictions. It does less on the cutting edge but covers the core use cases well and keeps getting better.
Pick Elasticsearch if its advanced features or ecosystem justify the additional cost and licensing considerations. Pick OpenSearch if the fundamentals are what you need and you value simplicity, cost-effectiveness, and licensing freedom.
The honest truth is that most search workloads don’t need the bleeding edge. They need reliability, performance, and operational sanity. Both platforms deliver that. Make your decision based on your cloud provider, your budget, your licensing requirements, and which ecosystem fits your team–not on feature comparison charts for capabilities you may never use.