Elasticsearch vs OpenSearch (2026): The Fork, the Licenses, and Which to Self-Host

If you’re a self-hoster who wants a search engine with a license you fully control, OpenSearch is usually the safer long-term bet — it’s Apache-2.0 and governed by a neutral foundation (the OpenSearch Software Foundation, under the Linux Foundation), so there’s no single vendor who can change the terms under you. Elasticsearch is the original engine and still the feature and ecosystem leader, but it’s controlled by Elastic and licensed under AGPLv3 / Elastic License v2 / SSPL — terms you should read carefully before you build on it. The two share a common ancestor: OpenSearch is AWS’s 2021 fork of Elasticsearch (and Kibana) made because Elastic moved off Apache-2.0. This comparison is the fork story, told for someone deciding which to self-host.

This is a search-engine-vs-search-engine matchup, but both also do vector search, so it sits next to our vector-DB comparisons. If your job is pure semantic retrieval for RAG rather than a full search/analytics platform, a dedicated vector engine is usually the lighter tool — see best self-hosted vector databases and Qdrant vs Pinecone. For the concept of what a vector database is, see what is a vector database.

Side-by-side comparison

	Elasticsearch	OpenSearch
Origin	Original engine (Elastic, 2010)	AWS fork of Elasticsearch/Kibana 7.10 (announced Jan 2021, GA July 2021)
License	AGPLv3 / Elastic License v2 / SSPL (triple-licensed)	Apache-2.0
Governance	Elastic (single vendor)	OpenSearch Software Foundation, under the Linux Foundation
Core language	Java	Java
GitHub stars (June 2026)	77.1k	13.2k
Vector search	Yes — dense vectors / kNN (built on Lucene)	Yes — Vector Engine / k-NN (Lucene, FAISS, NMSLIB)
Self-host	Yes — your infrastructure	Yes — your infrastructure
Managed by original maker	Elastic Cloud	AWS (Amazon OpenSearch Service) and others

Star counts are GitHub’s rounded figures as of June 2026 and drift over time — note that raw star counts partly reflect repo age (Elasticsearch is far older), so weight them as a rough proxy for reach, not a quality ranking. License and governance are the stable facts that matter most for self-hosters.

The fork story (why there are two)

Elasticsearch shipped under Apache-2.0 for its first decade and became the default open-source search engine — widely adopted, including by cloud providers (notably AWS) offering managed services built on it.

In 2021 (the 7.11 release), Elastic relicensed the source: the Apache-2.0 code moved to a dual license of Server Side Public License (SSPL) and the Elastic License, partly to stop cloud providers from offering Elasticsearch as a competing managed service. SSPL is a copyleft license but is not OSI-approved and is not considered open source.

In response, AWS forked Elasticsearch and Kibana 7.10 (the last Apache-2.0 version), announcing OpenSearch in January 2021 and releasing 1.0 for production in July 2021, keeping it under Apache-2.0.

In 2024, Elastic added AGPLv3 — an OSI-approved open-source license — as a third option alongside ELv2 and SSPL, restoring an open-source path for Elasticsearch (this is sometimes described as Elastic’s “return to open source”). And in 2024–2025, OpenSearch moved from AWS stewardship to a neutral foundation: the OpenSearch Software Foundation, a project of the Linux Foundation.

The upshot for a self-hoster: Elasticsearch is open-source-available again (you can pick AGPLv3), but it’s still steered by one vendor under triple-licensing you have to navigate. OpenSearch is plain Apache-2.0 under neutral, foundation governance — the option you’d choose specifically because no single company can change the terms under you.

License and governance: the heart of the decision

For self-hosters, this is the dimension the whole choice turns on.

• Elasticsearch — AGPLv3 / Elastic License v2 / SSPL (triple-licensed), single-vendor. You choose which of the three terms to use. AGPLv3 is OSI-approved open source but is strong copyleft — running a modified version as a network service can trigger source-availability obligations, which some organizations avoid by policy. ELv2 is source-available but restricts offering it as a competing managed service. SSPL is copyleft and not OSI-approved (not considered open source). All three are governed by Elastic, a single vendor — which is exactly the arrangement that produced the 2021 relicensing in the first place.
• OpenSearch — Apache-2.0, neutral foundation. A single, permissive, OSI-approved license with no copyleft and no SaaS restriction, under the OpenSearch Software Foundation (Linux Foundation). There’s no Contributor License Agreement and, crucially, no single company that can relicense it under you. For a team that wants “a license we control,” that combination — permissive license plus neutral governance — is the whole pitch.

The honest framing: if license simplicity and protection from future vendor relicensing are your priority, OpenSearch’s Apache-2.0-under-a-foundation is the lower-risk choice. If AGPLv3 (or ELv2/SSPL) fits how you deploy and you value Elastic’s roadmap, Elasticsearch is perfectly usable open-source-available software — you just need to deliberately confirm the license terms against your deployment.

Features and vector search

Both are mature, Lucene-based search and analytics engines: full-text search, aggregations/analytics, dashboards (Kibana for Elasticsearch, OpenSearch Dashboards for OpenSearch — itself a fork of Kibana), and an ingest/observability ecosystem.

On vector search, both are genuinely capable:

• Elasticsearch supports dense-vector fields and kNN search built on Lucene, with hybrid (keyword + vector) retrieval, and Elastic has invested heavily in vector/semantic features as part of its AI search positioning.
• OpenSearch ships a dedicated Vector Engine with k-NN search backed by Lucene, FAISS, and NMSLIB, plus hybrid search and ML features. Recent releases highlight vector-search performance work (e.g. faster concurrent k-NN search).

Because the two share a 7.10 ancestor, the baseline feature set overlaps heavily. They have diverged since 2021, though — feature parity is no longer exact, the APIs and newer features differ, and direct drop-in compatibility is not guaranteed for newer functionality. The practical reading: both will serve full-text and vector search well; pick on license, governance, ecosystem, and managed-service fit rather than on the assumption that they’re interchangeable.

Worth a caveat for RAG builders: a full search/analytics platform like either of these is heavier than a purpose-built vector database. If semantic retrieval is the only job, a dedicated engine (see best self-hosted vector databases and Qdrant vs Pinecone) is usually lighter to run. Reach for Elasticsearch/OpenSearch when you want full-text search, analytics, logs/observability, and vectors in one platform.

Performance

Both are Java/Lucene engines with broadly similar architecture, and because OpenSearch began as a fork their baseline performance characteristics are similar. Each project has optimized independently since, and you’ll find vendor-published benchmarks on both sides — treat all of them with the usual skepticism, since search performance depends heavily on data shape, query mix, mapping/index design, JVM tuning, and hardware, and benchmarks are typically run by a party with a stake in the result.

The defensible takeaway: for most workloads, the engine won’t be your bottleneck — your mapping, query design, shard strategy, and JVM/hardware sizing will dominate. Benchmark on your own data and query pattern rather than choosing on a headline number from either camp.

Self-hosting and operations

Both are self-hostable on your own infrastructure, and both carry the operational weight typical of a JVM-based, Lucene search cluster — this is heavier than a single-binary engine like Meilisearch or a single-image vector DB like Qdrant.

• Expect to run a JVM, tune heap and garbage collection, plan shards and replicas, and operate a multi-node cluster for production resilience. Both ship Docker images and Helm charts, and both have large operations communities.
• Elasticsearch self-hosting means running the distribution under the license you selected (AGPLv3/ELv2/SSPL) and operating it yourself, separate from Elastic Cloud.
• OpenSearch self-hosting is plain Apache-2.0, with no license decision to make and no SaaS restriction to worry about — a meaningful simplification if you might one day offer it as part of a service.

The operational effort is comparable between the two; the difference that matters to a self-hoster is the license you’re operating under, not the day-to-day ops, which are similar. If “I want to run this myself, indefinitely, under a license nobody can change on me” is the requirement, OpenSearch’s Apache-2.0 is the cleaner answer.

Cost and pricing

Both engines are free to self-host — the cost is the infrastructure they run on. A Lucene/JVM search cluster is heavier than a single-binary site-search engine, so expect to size for RAM/heap and multiple nodes at production scale; this is a bigger box (or cluster) than the ~$20–30/mo VPS that suits Meilisearch or a small vector index.

On the managed side:

• Elasticsearch → Elastic Cloud, Elastic’s own managed offering (plus self-managed under your chosen license).
• OpenSearch → Amazon OpenSearch Service and other providers, since its Apache-2.0 license permits third parties to offer it as a managed service — that very openness (the thing the 2021 relicensing was meant to prevent) means more managed-hosting competition for OpenSearch.

The self-hosting cost story is similar between them. The license is what changes the strategic cost picture: with OpenSearch you’re never one relicensing announcement away from a forced decision, and you have a competitive managed-hosting market if you ever want to offload ops.

When to pick which

Choose OpenSearch if:

• You want a permissive, OSI-approved license (Apache-2.0) with no copyleft and no SaaS restriction.
• You want neutral, foundation governance (Linux Foundation) so no single vendor can relicense it under you.
• You want a competitive managed-hosting market (AWS and others) as a fallback.
• “A license and project we fully control, long-term” is the priority.

Choose Elasticsearch if:

• You want the original engine, its latest features, and the largest ecosystem, and AGPLv3 (or ELv2/SSPL) fits your deployment.
• You’re already invested in the Elastic Stack (Kibana, integrations, Elastic Cloud) and value Elastic’s roadmap.
• Your legal team has confirmed the license you’ll use is acceptable for how you deploy.

Verdict

For a self-hoster whose top priority is a license they control, OpenSearch is the safer long-term bet — plain Apache-2.0, neutral governance under the Linux Foundation, capable vector search, and no single vendor who can change the terms under you. That is precisely the scenario it was forked to provide. Elasticsearch remains the feature and ecosystem leader, it’s open-source-available again via AGPLv3, and it’s an excellent choice when you want its latest capabilities and the Elastic Stack — provided you’ve confirmed that AGPLv3 (or ELv2/SSPL) fits how you deploy. The deciding question for most self-hosters isn’t raw performance — the two are close, having shared an ancestor — it’s which licensing and governance model you want to build the next decade on. OpenSearch answers “a permissive license under neutral stewardship”; Elasticsearch answers “the leading engine and ecosystem, on Elastic’s terms.”

FAQ

Is OpenSearch the same as Elasticsearch? Not anymore. OpenSearch began in 2021 as AWS’s fork of the last Apache-2.0 version of Elasticsearch and Kibana (7.10), so they share an ancestor and a lot of baseline behavior. But they’ve diverged since — different licenses, governance, and newer features — so they’re no longer drop-in compatible for the latest functionality. Plan a migration deliberately rather than assuming interchangeability.

Why did OpenSearch get created? Because Elastic relicensed Elasticsearch off Apache-2.0 in 2021 (to SSPL + the Elastic License), partly to stop cloud providers from offering it as a managed service. AWS forked the last Apache-2.0 release to keep an openly licensed engine going, and OpenSearch is now governed by the OpenSearch Software Foundation under the Linux Foundation.

What license is Elasticsearch under in 2026? Elasticsearch is triple-licensed: AGPLv3 (OSI-approved open source, added in 2024), Elastic License v2 (source-available, restricts competing managed services), and SSPL (copyleft, not OSI-approved). You choose which terms to use. OpenSearch, by contrast, is plain Apache-2.0.

Do both support vector search for RAG? Yes. Elasticsearch supports dense-vector kNN search built on Lucene with hybrid retrieval; OpenSearch ships a Vector Engine with k-NN backed by Lucene, FAISS, and NMSLIB. Both work for semantic retrieval. That said, a full search/analytics platform is heavier than a purpose-built vector database — if RAG is the only job, a dedicated engine like Qdrant is usually lighter to run. See best self-hosted vector databases.

Which is better to self-host, Elasticsearch or OpenSearch? Both are self-hostable Java/Lucene engines with comparable operational weight (JVM, heap tuning, multi-node clusters). The difference that matters for self-hosters is licensing: OpenSearch is Apache-2.0 under neutral foundation governance, so no single vendor can change the terms under you — the lower-risk choice if “a license we control” is the priority. Elasticsearch is a great self-hosted engine too if AGPLv3 (or ELv2/SSPL) fits your deployment and you want its latest features.

---

Aquila is the independent guide to private, self-hosted AI search — search you own instead of rent. If pure semantic retrieval is the job, compare dedicated engines in Qdrant vs Pinecone and best self-hosted vector databases, or learn the fundamentals in what is a vector database. Own your search.