Elasticsearch vs OpenSearch
Origin: The 2021 Fork
OpenSearch was born in 2021 when AWS forked Elasticsearch 7.10.2 — the last version under Apache 2.0 — after Elastic changed its license to SSPL/Elastic License to protect against cloud providers (primarily AWS) running Elasticsearch as a managed service without contributing back.
The fork preserved the full open-source baseline. Since then, both projects have evolved independently, with feature sets, performance characteristics, and community governance diverging meaningfully.
In September 2024 Elastic added an AGPLv3 option alongside SSPL, but enterprise-grade features remain behind the commercial tier. OpenSearch joined the Linux Foundation in the same period, strengthening its community governance.
Licensing
| Elasticsearch | OpenSearch | |
|---|---|---|
| License | SSPL + Elastic License (+ AGPLv3 option) | Apache 2.0 |
| Governance | Elastic (commercial) | AWS + Linux Foundation (community) |
| Self-host freedom | Restricted for SaaS cloud providers | Unrestricted for all uses |
| Enterprise features | Some behind paid tier | All features open |
For most end-user deployments (internal apps, products), Elasticsearch’s SSPL is not a practical restriction — it targets SaaS providers. For organizations with strict open-source compliance policies, OpenSearch’s Apache 2.0 is the simpler path.
Performance
2024–2025 benchmarks consistently favor Elasticsearch:
| Workload | Gap |
|---|---|
| Text search / aggregations | Elasticsearch 40–140% faster |
| Vector / ANN search | Elasticsearch 2–12x faster |
The performance gap stems from Elastic’s continued investment in proprietary Lucene optimizations, quantization (see BBQ), and query execution tuning.
Important caveat: Several widely-cited benchmarks originate from Elastic’s own engineering blog. The most rigorous independent study is Trail of Bits (March 2025), which confirmed the gap across a four-month realistic workload test.
The gap narrows at smaller scale and for simpler queries. Organizations migrating from OpenSearch to Elasticsearch at large scale have reported 40–58% infrastructure cost reductions — but this reflects the high end of complex, high-throughput deployments.
Feature Differences
Both share the same Lucene core and a largely compatible query DSL. Divergence has grown since 2021:
| Feature | Elasticsearch | OpenSearch |
|---|---|---|
| Sparse retrieval | ELSER — mature, proprietary, zero-shot | Neural Sparse — open, maturing |
| Vector backends | Native Lucene HNSW | Faiss, nmslib, Lucene (k-NN plugin) |
| Max vector dimensions | 4,096 | 16,000 |
| Dense vector quantization | BBQ (32× binary), int8 scalar | int8 scalar |
| Hybrid search | RRF + linear combination | Normalization pipeline + RRF |
| Search pipelines | Inference pipeline (Elastic stack) | Composable search pipelines |
| Query language | ES DSL + SQL | ES DSL + PPL (Piped Processing Language) |
| Visualization | Kibana | OpenSearch Dashboards |
| Feature cadence | Faster — commercial R&D | Slower — community contributors |
Cloud Deployment
- Amazon OpenSearch Service — fully managed on AWS; native IAM, VPC, CloudWatch, Bedrock integration; simplest for AWS-native stacks; no multi-cloud
- Elastic Cloud — managed on AWS + GCP + Azure; broader cloud footprint; higher cost; backed by Elastic SLAs
When to Choose OpenSearch
- Infrastructure is AWS-native and you want tight Bedrock / IAM / Kinesis integration
- Open-source licensing is non-negotiable (compliance policy, redistribution, or SaaS provider)
- Budget is a primary constraint and workloads are not performance-critical at scale
- You want community influence over the roadmap
- Vector dimensionality requirements exceed 4,096
When to Choose Elasticsearch
- Query and vector performance is critical (high-traffic production, complex ranking)
- You need Elastic’s ML features: ELSER, BBQ quantization, advanced anomaly detection
- Multi-cloud or non-AWS infrastructure
- Commercial support SLAs are required
- You’re already in the Elastic ecosystem (Kibana, APM, Fleet)
Practical Guidance
For greenfield AWS-native projects, OpenSearch Service is the path of least resistance — managed, integrated, no licensing friction. For high-performance production search where every millisecond or every dollar of infrastructure counts, the Elasticsearch performance advantage becomes real at scale.
Both engines support hybrid BM25 + vector search, which is where most modern search stacks are heading. The APIs are similar enough that migrating between them, while non-trivial, is feasible.
Related Notes
- Search Platforms — broader platform selection framework
- Elasticsearch — tool page
- OpenSearch — tool page
- Wormhole Vectors Beyond Hybrid Search in OpenSearch — advanced OpenSearch retrieval pattern
- Innovating Search Experience with Amazon OpenSearch and Amazon Bedrock — AWS-native RAG on OpenSearch
Sources
- OpenSearch vs. Elasticsearch A Comprehensive Comparison in 2025 — Frank Goortani; balanced overview
- Elasticsearch vs. OpenSearch (2025) The Definitive Showdown — Jagadeesh Chandra; Elasticsearch-favorable; cites Elastic’s own benchmarks heavily