Choosing between elasticsearch vs opensearch in 2026 is less about raw speed and more about who controls the code and what you are allowed to do with it. Both engines came from the same source tree, forked in 2021, and now behave like estranged siblings: familiar, mostly compatible, but no longer interchangeable. This guide walks through the differences that actually change your architecture and your bill.
What changed in 2026
The fork story is settled but the tooling around it has matured.
- OpenSearch is now governed by the Linux Foundation, not AWS alone. That answers the biggest early criticism — that OpenSearch was a single-vendor project wearing an open-source badge.
- Elasticsearch added an AGPLv3 license option alongside SSPL and the Elastic License. So Elasticsearch is technically "open source" again by OSI-adjacent standards, but the terms still block you from offering it as a managed cloud service without a deal.
- Vector search and hybrid retrieval matured on both sides. With RAG and semantic search now mainstream, both engines lean hard on kNN and dense vectors, though Elastic tends to ship the newer knobs first.
- Client libraries diverged for real. The official Elasticsearch clients refuse to talk to OpenSearch clusters, and vice versa. Community clients paper over this, but plan for it.
The license split is the real story
This is the single decision that matters most. Elasticsearch is source-available under a mix of SSPL, the Elastic License 2.0, and AGPLv3. The practical restriction: you cannot take Elasticsearch and sell it as a hosted search service that competes with Elastic. For 95% of teams building an app, that restriction never bites.
OpenSearch stays under the Apache 2.0 license — genuinely permissive, no strings, embed it anywhere. If your legal team or your product model requires a truly open license (you are reselling, embedding in an appliance, or shipping to license-sensitive customers), OpenSearch wins on that axis alone.
Feature and ecosystem comparison
| Area |
Elasticsearch |
OpenSearch |
| License |
SSPL / Elastic / AGPLv3 |
Apache 2.0 |
| Governance |
Elastic (single vendor) |
Linux Foundation |
| Dashboards |
Kibana |
OpenSearch Dashboards |
| Managed cloud |
Elastic Cloud, many providers |
AWS OpenSearch Service, others |
| New features first |
Usually here |
Follows, sometimes months later |
| Query language |
Query DSL + ES|QL |
Query DSL + PPL |
| Vector / kNN search |
Mature, frequent updates |
Mature, solid |
| Cost to self-host |
Free tier + paid features |
Free, all features |
The honest summary: Elasticsearch is the trendsetter, OpenSearch is the safe commons. Advanced ML, ES|QL, and some security features sit behind Elastic's paid tiers, while OpenSearch bundles equivalents (like fine-grained access control) for free.
Performance and cost, without the hype
Benchmark wars between these two are mostly noise. For typical log and full-text workloads they land close enough that your mapping, sharding, and hardware choices matter far more than the engine name. Do not pick based on someone's cherry-picked graph — run your own test on your own data before you commit. Numbers here are directional; verify current figures yourself.
On cost, the split shows up in features, not the base engine. With Elasticsearch, capabilities like advanced alerting or machine learning may require a paid subscription. With OpenSearch, those are included, but you are on your own for support unless you buy it from a vendor. Managed pricing (Elastic Cloud vs AWS OpenSearch Service) varies enough that you should price your exact node sizes rather than trust a blog table.
How to actually choose
- Already on AWS and want zero license worry? OpenSearch is the low-friction default.
- Need the newest vector, ML, or ES|QL features and want vendor support? Elasticsearch.
- Building a product you resell or embed? OpenSearch, for the Apache 2.0 license.
- Migrating an old Elasticsearch 7 cluster? Either works, but re-test every query and client — do not assume compatibility.
What to skip: agonizing over a 5% benchmark difference, and assuming a future migration between the two will be painless. The API drift is real and grows every release.
FAQ
Is OpenSearch a drop-in replacement for Elasticsearch?
Only for clusters near version 7.10, and even then the official clients block cross-talk. Newer features and clients are not compatible, so treat a switch as a migration, not a swap.
Is Elasticsearch open source in 2026?
Sort of. The AGPLv3 option makes it open-source by license, but SSPL and the Elastic License still restrict offering it as a managed service. OpenSearch remains the cleanly permissive choice.
Which is faster?
Neither, meaningfully, for most workloads. Your indexing strategy and hardware dominate. Benchmark on your own data.
Which has better vector search for RAG?
Both handle kNN and hybrid search well. Elasticsearch usually ships new retrieval features first; OpenSearch catches up and keeps them free.
Where to go next
Once you have picked an engine, wire it up safely: read API authentication explained before you expose a search endpoint, brush up on async/await so your ingestion pipeline does not block, and if you are prototyping queries with an assistant, see our take on the best AI coding assistants.