Elasticsearch: The 70k-Star Search Engine That Went SSPL and Forked Into OpenSearch

Here is the oldest and largest license fork in this series, and the template every later fork copied: Elasticsearch spent a decade as the default open-source search and logging engine under Apache 2.0, then in January 2021 its parent company changed the license, and AWS forked the last open version into OpenSearch. If you run log analytics, full-text search, or RAG retrieval today, you are almost certainly running one of these two — and they are no longer the same product. That fork predates the Redis and Terraform splits by two to three years, and it set the playbook.

For ten years Elasticsearch was the boring, reliable, permissively licensed engine behind site search, application search, and the ELK logging stack (Elasticsearch, Logstash, Kibana). Apache 2.0 meant anyone could build a managed service, fork it, or embed it without asking. Then Elastic decided the cloud providers were reselling its work, changed the license, and within three months AWS had forked the last Apache version. This is the story of that change, what it means for you, and how to make the call in 2026.

This review covers what Elasticsearch is, the Apache years, the January 2021 relicensing, the AWS fork into OpenSearch, API compatibility in practice, Elastic's AGPL olive branch in 2024, how vector search and ML diverged, real self-hosting and managed costs, where your data actually lives, and an honest verdict for a sovereignty-minded operator.

1. What Elasticsearch Actually Is

Elasticsearch is a distributed, RESTful search and analytics engine built on Apache Lucene. You index documents (JSON) into it, and it gives you full-text search, structured filtering, aggregations, and — increasingly — vector search for AI retrieval. It is the "E" in ELK (Elasticsearch, Logstash, Kibana) and the backbone of countless log pipelines, site search boxes, and observability platforms. Kibana is its visualization layer; Logstash (or Beats/Fluentd) feeds it data.

The core job Elasticsearch takes is "make this data searchable and aggregatable at scale." A single node handles gigabytes; a cluster handles petabytes across many shards and replicas. Its near-real-time indexing (documents become searchable within a second or so) and its rich query DSL made it the default for anything beyond a simple SQL LIKE. When AWS forked it, it forked Kibana too (as OpenSearch Dashboards), so the fork was the whole stack, not just the engine.

2. The Apache Years (2010–2021)

From its 2010 release until January 2021, Elasticsearch shipped under Apache 2.0 — permissive, OSI-approved, no copyleft, free for any use including commercial and managed services. That freedom is why AWS built Amazon Elasticsearch Service (later Amazon OpenSearch Service) on the open codebase, why countless vendors embedded it, and why it became the logging default. Apache 2.0 is the same family of license that let Redis and Terraform become ubiquitous before their own relicensing events.

Same setup as the later forks: the permissive license built the market, the market made the engine the default, being the default made it the thing cloud providers resold, and the company decided the open license was giving away the commercial upside. Elastic had been moving modules (security, alerting, SQL) into its commercial X-Pack tier, but the core remained Apache. The 2021 change closed the Apache door on new versions.

3. January 2021: The SSPL/Elastic License Change

Starting with version 7.11 (January 2021), Elasticsearch and Kibana moved from Apache 2.0 to a dual model: the Server Side Public License (SSPL) and the Elastic License 2.0 (ELv2). Version 7.10 became the last Apache 2.0 release — and, exactly like Redis 7.2.4 and Terraform 1.5.x, it became the precise branch point for the fork. SSPL is the MongoDB-written license OSI rejects: offer the software as a service and you must release your entire service stack under SSPL. ELv2 is Elastic's own source-available license that forbids providing the software as a managed service to third parties and prohibits circumventing its licensing/security features, while allowing most other use.

For an ordinary user running Elasticsearch for their own search or logging, both licenses allow internal use. The restrictions target managed-service providers — chiefly AWS, whose Amazon Elasticsearch Service was the provocation. Elastic's stated goal was to stop cloud providers from reselling the open engine without a commercial agreement. The community reaction followed the now-familiar arc: the license that built the ecosystem was retracted, and a fork was inevitable.

4. Why Elastic Did It

The motivation was the same value-capture problem as Redis, Terraform, and MongoDB: hyperscalers capture the recurring revenue of "managed Elasticsearch" while Elastic carries the core engineering cost. Elastic had tried to monetize via X-Pack (security, monitoring, alerting, machine learning) under the Elastic License, but the free Apache core remained what everyone deployed. By moving the core to SSPL/ELv2, Elastic aimed to force managed providers to either pay or stop reselling the unmodified software. The strategy is defensible as business and infuriating as community action — and the fork proved which side the ecosystem weighed more heavily.

5. OpenSearch: The Fork From 7.10.2

AWS did not wait. In April 2021 it forked Elasticsearch 7.10.2 and Kibana 7.10.2 — the last Apache versions — and rebranded them as OpenSearch and OpenSearch Dashboards, keeping Apache 2.0. AWS had already been shipping Open Distro for Elasticsearch (an Apache 2.0 distribution bundling the security, alerting, and SQL plugins Elastic kept commercial), so it had the muscle memory and the code to fork cleanly. OpenSearch reached 1.0 GA in July 2021 and absorbed Open Distro.

The governance evolution mirrored the later forks: on September 16, 2024, AWS transferred OpenSearch to the new OpenSearch Software Foundation under the Linux Foundation, making it vendor-neutral rather than AWS-owned. That move mattered because it removed the "this is just AWS's thing" objection and signaled long-term neutrality. By 2026 OpenSearch had reached 3.x (3.8.0 in August 2026), with roughly 13,700 GitHub stars — smaller than Elasticsearch's ~70k, but a serious, foundation-governed project with its own roadmap.

6. API Compatibility in Practice

The fork shares code with Elasticsearch 7.10, so for most CRUD, indexing, and basic search operations you can swap one for the other. A document index call and a basic match query look identical on both. OpenSearch reported itself as Elasticsearch 7.10.2 to legacy clients via compatibility.override_main_response_version for years, easing migration. But that shim was removed in OpenSearch 3.0 — an ES client that depends on the reported version no longer works out of the box on 3.x. The honest compatibility number is "~95% with the ES 7.10 API shape," and it is eroding as the projects diverge.

The practical takeaway: migrating from Elasticsearch 7.10 to OpenSearch is relatively straightforward via the reindex API or snapshots, and many teams did exactly that. Migrating between current Elasticsearch 9.x and OpenSearch 3.x is harder, because each has added features and APIs the other lacks. The fork is no longer "old Elasticsearch"; it is a separate product that happens to speak a dialect of the old language.

7. Elastic's AGPL Olive Branch (2024)

In August 2024, with Elasticsearch 8.16.0, Elastic added AGPLv3 as a third license option (alongside SSPL and ELv2). AGPLv3 is OSI-approved, so Elasticsearch became tri-licensed and, by the strict definition, "open source again" — the same playbook Redis used in 2025. As of 2026 Elasticsearch is at 9.5.x (9.5.3 in September 2026), and the AGPL option covers the free portions of the source; advanced management, security, and ML features still require an Elastic subscription.

The community reaction was, again, "too late." By 2024 OpenSearch had its own governance, roadmap, and AWS backing, and the momentum had shifted. The AGPL option is real and useful for teams that want an OSI license while staying on Elasticsearch, but the license change proved the promise could move once, which is the permanent risk OpenSearch was built to eliminate.

8. How Vector Search Diverged

This is where the two engines most clearly split for AI workloads in 2026. Elasticsearch uses Lucene's HNSW implementation for approximate nearest-neighbor search, and in 9.x defaults to Better Binary Quantization (BBQ) for higher-dimensional dense vectors, with ACORN-1 for filtered vector search and a DiskBBQ format to cut memory. It integrates tightly with its query DSL for hybrid search (vector + BM25 keyword) and offers ELSER, a sparse encoding model trained for retrieval, plus an AI Assistant and Agent Builder (MCP/A2A servers).

OpenSearch's k-NN plugin supports Faiss and Lucene engines (Faiss became default in 3.0; NMSLIB was removed), with smart filtering and exact k-NN via script scoring. Its ML Commons plugin hosts embedding models, cross-encoder rerankers, and sparse encoders on dedicated ML nodes; the neural search plugin does query/document vectorization; and OpenSearch 3.0 added native MCP support so AI agents can talk to a cluster directly. Both work as the retrieval layer for RAG, and both integrate with LangChain/LlamaIndex. The difference is implementation maturity and which AI features are first-class — Elasticsearch leads on integrated semantic/vector polish; OpenSearch leads on open, plugin-based, vendor-neutral AI tooling.

9. Machine Learning and Security Tiers

Elasticsearch made security (TLS, RBAC, native users, API keys) free in its Basic license, but field- and document-level security, audit logging, and SSO remain paid. OpenSearch provides RBAC, field-level security, audit logging, and alerting for free in its Apache distribution. On the ML side, Elasticsearch has built-in ML and anomaly detection; OpenSearch has ML Commons. For log analytics and security use cases, OpenSearch's free security tier is a meaningful cost and compliance advantage, while Elasticsearch's paid tier unlocks finer-grained controls.

10. Performance: The Benchmark Dispute

The benchmark record is genuinely contradictory, which is itself the lesson. Elastic's February 2026 vendor-published tests showed Elasticsearch up to 8x faster on filtered vector search (9.3.0 vs OpenSearch 3.5.0). The independent Trail of Bits test commissioned by AWS (March 2025) found OpenSearch 2.17.1 up to 1.56x faster overall on the Big5 mixed workload, with Elasticsearch 2.42x faster on text queries. Different versions, different workloads, different funders. The honest summary: for most workloads performance is comparable, within single-digit percentages; Elasticsearch edges the latest hardware/vector optimizations, OpenSearch invests in segment replication and remote-backed storage to cut indexing cost at petabyte scale. Do not pick a side on a vendor benchmark.

11. Real Cost: Self-Hosting vs Managed

Self-hosting either engine is "free" in license terms only with OpenSearch (Apache) or Elasticsearch's AGPL option. The real costs are infrastructure and operations, and they are significant because search engines are memory- and disk-hungry. A small three-node cluster for modest log volume runs on a few hundred dollars a month of VM/storage, plus your time to tune shards, monitor heap, and manage snapshots. At petabyte scale, OpenSearch's tiered storage (hot/warm/ultrawarm/cold integrated with S3) is documented as cheaper for log analytics; Elasticsearch's vector search is often faster for semantic re-ranking at scale.

Managed services: Amazon OpenSearch Service is the AWS-native option and trails the open release line (supports up to OpenSearch 3.5). Elastic Cloud runs on AWS, GCP, and Azure with first-party SLAs and the latest Elasticsearch features, at a commercial price. The honest cost table: self-host OpenSearch = low license cost, high ops cost, cheapest at scale; Elastic Cloud = high direct cost, low ops cost, richest features and multi-cloud; Amazon OpenSearch Service = moderate cost, low ops cost, AWS-integrated. Pick the row that matches your cloud and team size.

12. Data Sovereignty: Where Your Indexes Live

This is the part a sovereignty-minded operator must internalize. Both engines are self-hostable: your indexes, documents, and aggregations live on hardware you control, in a region you choose, with no mandatory telemetry shipping your data offsite. You can run either air-gapped, encrypt at rest with your own keys, and replicate only to nodes you own. Unlike a purely hosted search API, you hold the data and the query path.

The sovereignty nuance is governance and the security tier. With OpenSearch under the Linux Foundation (OpenSearch Software Foundation), no single vendor can relicense it out from under you, and its security features are free, so you are not pressured into a paid tier to get RBAC/audit. With Elasticsearch, the company changed the license once and keeps advanced security behind a subscription, so the "free" self-hosted path is more feature-limited unless you take the AGPL option and accept the historical license-risk signal. For operators who treat license stability as part of their data-sovereignty posture, OpenSearch's foundation governance is the stronger position.

13. When to Choose OpenSearch

Choose OpenSearch if you run on AWS and want native integration with Lambda, Kinesis, and IAM. Choose it if you need a strict Apache 2.0 license for legal or distribution reasons. Choose it if you want a vendor-neutral, community-governed project with free security and audit logging. Choose it if you are migrating from older Elasticsearch 7.x clusters and want a drop-in replacement. Choose it for petabyte-scale log analytics where tiered S3 storage cuts cost. For the majority of logging and search workloads, OpenSearch is the lower-risk, equally capable, foundation-governed default in 2026.

14. When to Choose Elasticsearch

Choose Elasticsearch if you need the latest vector search, semantic search, and LLM integration (ELSER, Vector Sets, BBQ). Choose it if you plan to use Elastic Observability or Elastic Security products. Choose it if you need official paid support from Elastic NV with strict SLAs. Choose it if your stack is multi-cloud and you want a single managed service across AWS, Azure, and GCP. Choose the AGPLv3 option if you want the OSI-approved license while keeping Elasticsearch's feature lead. Elasticsearch is not "the bad guy" — it is the feature-rich, commercially backed option with a more complicated license story, and for AI检索 workloads that lead is real.

15. The Honest Limitations

Both engines share search's inherent operational weight: they are JVM-based and heap-sensitive, sharding mistakes are expensive to fix, and a poorly tuned cluster burns money and latency. OpenSearch's limitation is narrower ecosystem gravity and a smaller contributor base than Elasticsearch's ~70k stars, plus the removed 7.10 compatibility shim that breaks some legacy clients on 3.x. Elasticsearch's limitation is the SSPL/ELv2 license risk and the paid security tier. Neither is "just install and forget" at scale; both demand cluster-discipline. The fork's real limitation is that it split a community, and some tooling now supports both — but that is a far smaller cost than being stuck under a license you cannot use.

16. Who Should Care in 2026

If you are a platform or SRE engineer, your default search/log engine for new services should be a conscious OpenSearch-versus-Elasticsearch decision, documented in your standards. If you are a CTO weighing license risk, Elasticsearch is the oldest and clearest case study in "the license you trusted can change, and a foundation can save the day" — it predates and inspired the Valkey and OpenTofu forks. The fork is mature, the migration from 7.10 is well-trodden, and the governance difference is permanent. Indifference is no longer defensible.

18. Indexing and Mapping Deep Dive

To use either engine well you have to respect mappings — the schema that defines how a document's fields are stored and indexed. Elasticsearch and OpenSearch auto-map fields by default, which is convenient and dangerous: a field that first appears as a number and later as a string causes a mapping conflict that breaks ingestion. The mature pattern is explicit mappings: define text versus keyword (full-text search versus exact match), integer versus scaled_float, date formats, and whether a field is index: false to save space. Both engines share this model because OpenSearch forked the 7.10 mapping code. The divergence appears only in newer field types (e.g., Elasticsearch's advanced vector types), so a 7.10-era mapping is portable; a 9.x Elasticsearch mapping is not. Define mappings explicitly and you keep the migration door open.

19. Aggregations: Turning Logs Into Answers

The feature that made Elasticsearch more than "search" is aggregations — the ability to compute histograms, terms, percentiles, and nested buckets over billions of documents in near-real-time. This is what powers Kibana dashboards and most observability use cases. OpenSearch inherited the full 7.10 aggregation framework and has extended it; Elasticsearch has extended it further with newer pipeline aggregations. For the common case (terms on a field, date histograms, percentile latency), the two are interchangeable. The lesson for operators: your dashboards are the real product on top of these engines, and they are portable between the two as long as you stay on the shared aggregation vocabulary. Build dashboards against the common feature set and you preserve the freedom to switch engines later.

20. The Logging Pipeline: ELK vs the OpenSearch Stack

The canonical log architecture is ingest (Beats/Fluentd/Logstash) → engine → visualization (Kibana or OpenSearch Dashboards). On the Elasticsearch side this is the classic ELK stack with Elastic's commercial X-Pack adding alerting and ML. On the OpenSearch side, the fork includes OpenSearch Dashboards plus free alerting, SQL, and anomaly detection plugins that Elastic kept behind X-Pack at the time of the fork. For a team standing up logging in 2026, the OpenSearch stack offers a more complete free experience end-to-end, while the ELK stack offers deeper integration with Elastic's paid Observability and Security products. The pipeline shape is identical; what differs is which features are free versus paid, and that difference is exactly the license story expressed as a bill.

21. Common Pitfalls

The pitfalls are JVM-shaped. Pitfall one: heap sizing wrong — too small and you OOM under load, too large and you trigger long GC pauses; the rule of thumb is half system RAM up to ~32 GB, with the rest for the OS page cache. Pitfall two: too many small shards, which exhausts cluster state and memory; aim for shards of 10–50 GB. Pitfall three: default mappings causing conflicts (see above). Pitfall four: unbounded index growth with no ILM (index lifecycle management) to roll over and delete old data — your cluster silently fills disk. Pitfall five, the one this article exists to prevent: assuming the Apache 2.0 license you trusted in 2020 still applies to new Elasticsearch versions — it does not after 7.11, and OpenSearch is the Apache continuation.

22. Sizing and Capacity Planning

Search engines are hungry. A node's heap, CPU, and especially disk I/O determine throughput, and SSDs are effectively mandatory at scale. A small three-node cluster for modest log volume (tens of GB/day) runs on a few hundred dollars a month of VM plus storage, plus your time to tune shards and watch disk. At petabyte scale, OpenSearch's tiering (hot/warm/ultrawarm/cold on S3) is the documented cost-saver, while Elasticsearch's vector optimizations matter more for AI检索. Plan capacity around ingest rate, retention window, and replication factor (one replica is the minimum for resilience, doubling storage). Either engine rewards disciplined ILM and shard sizing; both punish "just let it grow." Capacity planning is where the license choice meets the cloud bill, and OpenSearch's free tier makes the math more forgiving.

23. Search Relevance and the Query DSL

The query DSL is the engine's real interface, and it is shared between the two because OpenSearch forked it from 7.10. A bool query combines must, should, filter, and must_not clauses; match does full-text analysis while term does exact matching; range filters on dates and numbers; and function_score tweaks ranking. Relevance — BM25 by default — decides which of a thousand matches surfaces first. Both engines share this vocabulary, which is why a search application written against Elasticsearch 7.10 runs on OpenSearch with little change. The divergence is in newer relevance features (Elasticsearch's semantic/vector ranking, OpenSearch's neural search plugin), so keep your core queries on the shared DSL and you preserve engine portability. Relevance tuning is where search quality lives, and it is portable across the fork for the common case.

24. Security: What You Must Enable

A search cluster holds your logs, often including PII, so security is mandatory. At minimum: enable TLS for transport and HTTP, set up RBAC so applications get only the indices and operations they need, and decide on field/document-level security if you must restrict rows within an index. Here the license bites: OpenSearch gives you RBAC, field-level security, and audit logging for free under Apache, while Elasticsearch keeps field/document-level security and audit logging behind its paid Basic-plus tier. For a team with compliance obligations, OpenSearch's free security tier removes a budget line and a vendor-dependency at once. Either way, an unsecured cluster is a data-leak waiting to happen — encrypt, authenticate, and authorize before it holds anything real.

25. The Five-Year Outlook

Elasticsearch and OpenSearch will keep diverging on AI/vector features and cloud integrations while sharing the 7.10-era API for the workloads most teams actually run. Expect Elasticsearch to lead on integrated semantic search and multi-cloud Elastic Cloud, and OpenSearch to lead on open, vendor-neutral AI tooling and cost-efficient tiered storage. The foundation governance of OpenSearch is the structural guarantee that the license will not move again; Elasticsearch's AGPL option is a current promise, not a permanent one. The safe prediction: OpenSearch becomes the default for new open-source-aligned search and logging, Elasticsearch remains the AI-retrieval and enterprise choice. The durable lesson spans this whole series: the license is a first-class architectural input, and a foundation can rebuild what a company retracts.

26. A Minimal Indexing Example

The shape of the tool is easiest to see in a basic operation. To index a document you send a JSON object to an index endpoint; to search it you send a query DSL body. Both engines accept the same request shape because OpenSearch inherited the 7.10 API. A simple match query on a name field returns the documents whose analyzed text matches, ranked by relevance. Add a bool with a filter clause and you scope results without affecting ranking; add an aggs block and you get a terms breakdown or date histogram alongside the hits. This request/response pattern is the entire interface, and it is portable across the fork for the common case. The place you stop being portable is the advanced stuff — Elasticsearch's vector and semantic features, OpenSearch's neural search plugin — so keep your core queries on the shared DSL and treat the AI features as engine-specific extensions you opt into deliberately.

27. OpenSearch vs Elasticsearch: A Decision Table

Reduce the whole comparison to a few rows. License: OpenSearch is Apache 2.0 (unambiguously open); Elasticsearch is AGPL/SSPL/ELv2 tri-license (open via AGPL, with caveats). Governance: OpenSearch Software Foundation (Linux Foundation, neutral); Elasticsearch is single-vendor (Elastic, now with the AGPL option). Security tier: OpenSearch gives RBAC, field-level security, and audit logging free; Elasticsearch gates field/document-level security and audit behind paid tiers. Vector/AI: Elasticsearch leads on integrated semantic search and Vector Sets; OpenSearch leads on open, plugin-based neural search with native MCP. Managed: Amazon OpenSearch Service (AWS-native) versus Elastic Cloud (multi-cloud, first-party). Cost at scale: OpenSearch's tiered S3 storage is cheaper for log analytics; Elasticsearch's vector search is faster for semantic re-ranking. For new open-source-aligned projects, OpenSearch wins on license certainty and free security; for AI检索 and enterprise Elastic stacks, Elasticsearch wins on features. The table is stable because the fork's structural differences — foundation governance versus single-vendor — will not reverse.

28. Scaling Elasticsearch: Shards, Replicas, and Rolling Upgrades

Scaling a search cluster is mostly about shard and replica discipline. A shard is a Lucene index and the unit of distribution; a replica is a copy that provides both redundancy and read throughput. The classic mistake is too many small shards — each consumes cluster state, heap, and file handles — so the target is shards of roughly 10 to 50 GB. One replica is the minimum for resilience, doubling storage and giving you failover. Rolling upgrades (upgrading nodes one at a time so the cluster stays green) are routine on both engines and are why you want at least one replica. OpenSearch's tiering (hot/warm/ultrawarm/cold on S3) extends this by moving older, colder data to cheaper storage automatically via ILM, which is the documented cost-saver at petabyte scale. Elasticsearch offers similar ILM but leans more on its vector and enterprise features for differentiation. The operational truth is identical across the fork: size shards sensibly, keep one replica, automate lifecycle, and both engines scale; the license only changes who can relicense your foundation out from under you.

29. RAG and Vector Search: Choosing an Engine for AI Retrieval

The rise of retrieval-augmented generation made vector search a first-class workload, and this is where Elasticsearch and OpenSearch diverge most visibly in 2026. For RAG you need to store embeddings and run approximate nearest-neighbor search, usually blended with keyword BM25 in a hybrid query. Elasticsearch leads with Lucene HNSW, Better Binary Quantization for memory efficiency, and ELSER for sparse semantic encoding, all tightly integrated with its query DSL and LangChain/LlamaIndex. OpenSearch answers with its k-NN plugin (Faiss or Lucene), ML Commons for hosting models, a neural search plugin, and native MCP so AI agents query the cluster directly. Both work as the retrieval layer; the choice hinges on whether you want the deepest integrated semantic stack (Elasticsearch) or an open, vendor-neutral, plugin-based AI toolkit with free security (OpenSearch). For a sovereignty-minded AI builder, OpenSearch's Apache governance and free tier make it the lower-risk default, while Elasticsearch's polish suits teams already on Elastic Cloud.

30. Observability: Watching the Watcher

There is a pleasing recursion in running a search engine that powers your observability stack: you need to monitor the monitor. Both engines expose cluster health (_cluster/health), node stats, and index stats over HTTP, and both ship exporters for Prometheus so you can graph heap, JVM GC, search/index latency, and shard allocation in Grafana — the same observability front end reviewed elsewhere in this series. Key signals to alert on: cluster status yellow/red (a replica unassigned or a shard missing), disk watermark breaches (the cluster stops allocating shards when disks fill), and sustained high JVM heap or long GC pauses. A frozen search cluster during an incident is a particularly cruel failure because it is often the very tool you reach for to debug the incident. The fork does not change this operational reality; both engines are observable the same way at the API level, and the only difference is which dashboards and security features are free versus paid. Build the monitoring first, before you trust the cluster with production logs.

31. Getting Started: A Local Cluster in Minutes

The quickest way to feel the fork is to run both engines locally and compare. With Docker, docker run -p 9200:9200 elasticsearch:7.10.2 gives you the last Apache release; swap the image for opensearchproject/opensearch:3 and you have the foundation fork — same port, same _cluster/health endpoint, same basic queries. Point curl at localhost:9200, index a document, then search it; you will confirm the shared API this article rests on. Now open OpenSearch Dashboards versus Kibana and notice the free security plugin in OpenSearch versus the gated features in Kibana's Basic license. This ten-minute exercise makes the license difference tangible: same engine shape, different governance, different free tier. From there, stand up a three-node cluster, enable TLS, and set an ILM policy so old indices roll to cold storage. The takeaway is that adopting OpenSearch is not a migration nightmare; it is a different image with a freer license and a security tier that does not ask for a credit card. For a team evaluating the fork, this hands-on comparison beats any vendor benchmark. When you graduate from the demo to production, the same portability holds: your index templates, ILM policies, and dashboards transfer with only the advanced AI features needing engine-specific work. If you later need Elasticsearch's deeper semantic stack, the path back is a reindex plus a client bump, so the fork gives you optionality rather than lock-in. That reversibility is the quiet superpower of a code-compatible fork: you can choose, and you can change your mind without rewriting your pipeline.

32. Reading the License File (So You Don't Get Burned)

The most useful habit this series can leave you with is reading the LICENSE file before you standardize on a dependency, and re-reading it on major version bumps. For Elasticsearch, that means knowing 7.10 is Apache and 7.11+ is SSPL/ELv2 (with AGPL added in 8.16) — and that "open source again via AGPL" is a current option, not a permanent guarantee. For OpenSearch, the LICENSE is Apache 2.0 and the OpenSearch Software Foundation governance means it cannot quietly relicense. Make license review a checklist item in your architecture standards alongside security and cost. The teams that got burned by the 2021–2024 relicensing wave assumed the license was a permanent property of the software. It is not; it is a promise from the current rightsholder, and a foundation is a more durable promisor than a company with a revenue mandate. This discipline is the real takeaway of the entire fork saga. Concretely, add a step to your intake process: when a team proposes a new search or logging dependency, someone checks the current LICENSE and the project's governance, notes the major-version license boundary (7.10 Apache versus 7.11+ SSPL/ELv2 for Elasticsearch), and records it in the architecture decision log. It takes five minutes and would have saved countless teams from the 2021 surprise. The fork proved the community can rebuild a foundational tool in months; the least we can do is read the room before we commit.

33. Bottom Line

Elasticsearch did not die in 2021; it split, and it split first. The Apache core lives on as OpenSearch under the Linux Foundation — equally capable for most workloads, foundation-governed, and unambiguously open — while Elasticsearch itself became a tri-licensed, feature-rich, commercially steered platform with the deepest AI检索 integration. For new projects on logging and standard search, OpenSearch is the recommendation: better license certainty, free security tier, and governance that cannot pull the rug. For AI/vector-heavy or enterprise-Elastic workloads, Elasticsearch remains the capable choice. Either way, verify the current license of whatever you deploy against the project's LICENSE file — not against a blog post from before 2021 — because in this corner of infrastructure, the license is the feature that changed everything, and OpenSearch is the proof that the community can rebuild.

Elasticsearch: The 70k-Star Search Engine That Went SSPL and Forked Into OpenSearch — A License Deep Dive