Elasticsearch vs. OpenSearch: Unterschiede nach dem Fork

1. Die Geschichte des Forks: wie es 2021 dazu kam

Im Januar 2021 kuendigte Elastic an, Elasticsearch und Kibana ab Version 7.11 nicht mehr unter der Apache-2.0-Lizenz, sondern unter einer dualen Lizenzierung aus Elastic License und Server Side Public License, kurz SSPL, zu veroeffentlichen. Als Grund nannte Elastic vor allem AWS, das eine eigene, weitgehend identische Elasticsearch-Distribution als verwalteten Cloud-Dienst anbot, ohne signifikant zum Open-Source-Projekt beizutragen. Elastic sah darin ein Geschaeftsmodell, das vom offenen Code profitierte, ohne die Entwicklung mitzufinanzieren.

AWS reagierte wenige Wochen spaeter mit der Ankuendigung von OpenSearch, einem Fork des letzten Apache-2.0-lizenzierten Elasticsearch-Standes, Version 7.10.2. Gemeinsam mit weiteren Unternehmen aus dem Elasticsearch-Oekosystem, darunter Aiven, Red Hat und SAP, wurde OpenSearch unter Apache 2.0 weitergefuehrt und die Governance schrittweise in eine unabhaengigere Struktur ueberfuehrt. Der Fork-Zeitpunkt im Fruehjahr 2021 markiert damit den Beginn zweier getrennter Entwicklungspfade, die zuvor jahrelang denselben Code-Stand teilten.

Fuer Betreiber bestehender Elasticsearch-Cluster bedeutete die Ankuendigung eine grundsaetzliche Entscheidung: Bei Elasticsearch bleiben und die neue Lizenz akzeptieren, oder zu OpenSearch wechseln und damit auf die Apache-2.0-Linie setzen. Diese Entscheidung betraf nicht nur Lizenzfragen, sondern auch, welchem der beiden seither getrennt weiterentwickelten Projekte man langfristig folgen wollte.

2. SSPL, Elastic License und Apache 2.0 im Detail

Die Server Side Public License, entwickelt urspruenglich von MongoDB, verlangt von jedem, der die lizenzierte Software als Teil eines gehosteten Dienstes anbietet, den vollstaendigen Quellcode des gesamten Service-Stacks offenzulegen, nicht nur der Software selbst. Diese Klausel ist bewusst so weit gefasst, dass sie Cloud-Anbieter wie AWS praktisch zwingt, entweder den kompletten eigenen Infrastruktur-Code zu veroeffentlichen oder auf das Hosting der SSPL-lizenzierten Software zu verzichten. Kritiker bezeichnen die SSPL deshalb nicht als echte Open-Source-Lizenz im Sinne der Open Source Initiative, weil sie diese Freiheit einschraenkt.

Die Elastic License, die parallele Option zur SSPL, ist eine proprietaere Sourcecode-verfuegbare Lizenz, die den Einsatz erlaubt, aber bestimmte kommerzielle Nutzungen wie das Anbieten als verwalteter Dienst ausdruecklich untersagt. Beide Lizenzoptionen unterscheiden sich damit fundamental von der ursprünglichen Apache-2.0-Lizenz, die praktisch keine Nutzungseinschraenkungen kennt, auch nicht fuer kommerzielles Hosting durch Dritte. OpenSearch blieb konsequent bei Apache 2.0, was den Fork fuer Unternehmen attraktiv macht, die Wert auf eine unstrittige, permissive Lizenz legen.

Fuer die praktische Einordnung ist wichtig: Die Lizenzwahl betrifft in erster Linie Unternehmen, die die Software selbst als Cloud-Dienst weiterverkaufen wollen. Ein Unternehmen, das Elasticsearch oder OpenSearch ausschliesslich intern fuer eigene Anwendungen betreibt, ist von den Einschraenkungen der SSPL oder Elastic License in der Regel nicht direkt betroffen, sollte die Lizenzbedingungen aber dennoch juristisch pruefen lassen, bevor eine Entscheidung fuer eine der beiden Linien getroffen wird.

# Timeline overview, useful as a quick reference in migration decisions

# 2021-01: Elastic announces dual licensing (Elastic License / SSPL)
#          starting with Elasticsearch and Kibana 7.11
# 2021-04: AWS announces OpenSearch, forked from the last
#          Apache 2.0 release, Elasticsearch 7.10.2
# 2021-09: OpenSearch 1.0 released under Apache 2.0
# 2024-08: Elastic re-licenses Elasticsearch and Kibana under
#          AGPL (in addition to Elastic License and SSPL)

3. Elastics Rueckkehr zu Open Source 2024 und was sie bedeutet

Im August 2024 kuendigte Elastic an, Elasticsearch und Kibana zusaetzlich unter der GNU Affero General Public License, kurz AGPL, verfuegbar zu machen. Die AGPL ist von der Open Source Initiative offiziell als Open-Source-Lizenz anerkannt, anders als die SSPL. Elastic bietet seither drei parallele Lizenzoptionen an: die proprietaere Elastic License, die SSPL und die AGPL, wobei Nutzer die fuer sie passende Option waehlen koennen. Diese Kehrtwende aenderte die urspruengliche Streitfrage jedoch nicht grundlegend, da die Kernkritik am SSPL-Modell bestehen blieb und der Fork zu OpenSearch laengst ein eigenstaendiges Projekt mit eigener Roadmap geworden war.

Fuer bereits auf OpenSearch migrierte Teams aenderte die AGPL-Ankuendigung praktisch wenig, da eine erneute Migration zurueck zu Elasticsearch denselben Aufwand bedeuten wuerde wie der urspruengliche Wechsel. Fuer Teams, die bislang bei Elasticsearch geblieben waren, eroeffnete die AGPL-Option eine formal anerkannte Open-Source-Lizenz als Alternative zur SSPL, was insbesondere fuer Unternehmen relevant ist, deren interne Compliance-Richtlinien ausschliesslich OSI-anerkannte Lizenzen zulassen.

4. Architektonische Gemeinsamkeiten: was noch identisch ist

Trotz der Divergenz seit 2021 basieren sowohl Elasticsearch als auch OpenSearch weiterhin auf Apache Lucene als Such- und Indexierungs-Engine im Kern. Das bedeutet, dass grundlegende Konzepte wie invertierte Indizes, Segment-Merging, Analyzer-Ketten und die generelle Query-DSL-Struktur in beiden Systemen strukturell aehnlich funktionieren. Wer die Grundlagen von Mapping, Shards und Aggregationen in Elasticsearch verstanden hat, findet sich in OpenSearch schnell zurecht, weil die REST-API in weiten Teilen noch aus demselben gemeinsamen Ursprung stammt.

Auch grundlegende Betriebskonzepte wie Cluster-Discovery, Shard-Allocation und das Rolling-Upgrade-Verfahren folgen in beiden Systemen aehnlichen Prinzipien, da diese Mechanismen aus der gemeinsamen Codebasis vor dem Fork stammen und seither parallel, aber unabhaengig weiterentwickelt wurden. Diese strukturelle Naehe ist ein wichtiger Faktor, der Migrationen zwischen den Systemen technisch machbar macht, auch wenn sie mit Aufwand verbunden sind.

// Identical core query DSL in both systems, unchanged since the fork
GET /products/_search
{
  "query": {
    "bool": {
      "must": [{ "match": { "name": "wireless headphones" } }],
      "filter": [{ "term": { "in_stock": true } }]
    }
  },
  "aggs": {
    "by_brand": { "terms": { "field": "brand" } }
  }
}

5. Feature-Divergenz: Vektorsuche, ML und Security

Seit dem Fork haben beide Projekte eigenstaendige Features entwickelt, die im jeweils anderen System nicht oder nur in abweichender Form existieren. Bei der Vektorsuche fuer semantische Anwendungen und Retrieval-Augmented-Generation-Szenarien hat Elasticsearch mit dem Elastic Learned Sparse Encoder und tiefer Integration von Machine-Learning-Modellen in die eigene Plattform investiert, waehrend OpenSearch mit dem eigenen k-NN-Plugin und der Neural-Search-Funktionalitaet einen alternativen, aber funktional ueberlappenden Weg gegangen ist. Beide Ansaetze unterstuetzen mittlerweile Dense-Vector-Suche, unterscheiden sich aber in Implementierungsdetails, Standardalgorithmen und Integrationstiefe mit externen Embedding-Modellen.

Bei der Security-Funktionalitaet, ehemals ein zentraler Streitpunkt, weil Elastic X-Pack-Security-Features lange kostenpflichtig anbot, hat sich das Bild veraendert: OpenSearch integriert das OpenSearch Security Plugin mit rollenbasierter Zugriffskontrolle standardmaessig kostenlos, waehrend Elastic mittlerweile ebenfalls grundlegende Security-Funktionen wie TLS und rollenbasierte Zugriffskontrolle in der kostenlosen Basic-Lizenz anbietet. Fortgeschrittene Security-Features wie SAML-Integration oder Field-Level-Security bleiben bei Elastic teilweise kostenpflichtigen Tiers vorbehalten, waehrend OpenSearch einen Grossteil vergleichbarer Funktionen frei verfuegbar haelt.

Ein weiteres Divergenzfeld ist die Observability- und Dashboard-Schicht: Kibana bei Elasticsearch und OpenSearch Dashboards bei OpenSearch haben sich visuell und funktional zunehmend auseinanderentwickelt, mit unterschiedlichen Visualisierungstypen, Alerting-Mechanismen und Plugin-Oekosystemen. Wer stark auf spezifische Kibana-Visualisierungen oder umgekehrt auf OpenSearch-spezifische Dashboards-Plugins setzt, sollte diese Abhaengigkeit vor einer Migrationsentscheidung explizit pruefen.

// Elasticsearch: dense vector field for semantic search
PUT /articles
{
  "mappings": {
    "properties": {
      "embedding": {
        "type": "dense_vector",
        "dims": 384,
        "similarity": "cosine"
      }
    }
  }
}

// OpenSearch: comparable k-NN vector field
PUT /articles
{
  "settings": { "index.knn": true },
  "mappings": {
    "properties": {
      "embedding": {
        "type": "knn_vector",
        "dimension": 384
      }
    }
  }
}

6. Oekosystem und Governance: Stiftung versus Unternehmen

Ein oft unterschaetzter Unterschied liegt in der Governance-Struktur. Elasticsearch wird von Elastic N.V., einem boersennotierten Unternehmen, entwickelt und kontrolliert, das die finale Entscheidungshoheit ueber Roadmap, Lizenzierung und Release-Zyklen haelt. OpenSearch wurde 2024 formal in die OpenSearch Software Foundation unter dem Dach der Linux Foundation ueberfuehrt, mit dem erklaerten Ziel, die Governance auf mehrere Unternehmen und unabhaengige Contributor zu verteilen, statt sie bei einem einzelnen kommerziellen Akteur zu konzentrieren.

Diese strukturelle Differenz beeinflusst, wie Entscheidungen ueber neue Features, Breaking Changes und Deprecations getroffen werden. Bei Elasticsearch bestimmt letztlich Elastic als Unternehmen die Richtung, was schnelle, konsistente Produktentscheidungen ermoeglicht, aber auch bedeutet, dass kommerzielle Interessen des Unternehmens die Roadmap direkt beeinflussen koennen, wie der Lizenzwechsel 2021 gezeigt hat. Bei OpenSearch laeuft die Entscheidungsfindung ueber ein Foundation-Modell mit mehreren beteiligten Unternehmen, was potenziell langsamer, aber weniger von den Interessen eines einzelnen Akteurs abhaengig ist.

7. API-Kompatibilitaet und Client-Bibliotheken

Direkt nach dem Fork waren die REST-APIs von Elasticsearch 7.10.2 und dem daraus entstandenen OpenSearch praktisch identisch, was einfache Migrationen mit minimalem Codeaufwand ermoeglichte. Seither haben beide Projekte unabhaengig voneinander neue Endpunkte, Parameter und Verhaltensweisen eingefuehrt, sodass die API-Kompatibilitaet mit jeder neuen Major-Version schrittweise abnimmt. Elastic hat zudem in neueren Versionen technische Massnahmen eingefuehrt, die eine Verbindung von Drittanbieter-Clients, die sich als OpenSearch ausgeben, erschweren, was in der Community kontrovers diskutiert wurde.

Fuer Anwendungsentwickler bedeutet das konkret: Offizielle Client-Bibliotheken sind heute produktspezifisch, der Elasticsearch-Python-Client ist nicht mehr garantiert kompatibel mit OpenSearch-Clustern neuerer Version und umgekehrt. Wer eine Anwendung schreibt, die theoretisch gegen beide Systeme laufen soll, sollte sich auf den kleinsten gemeinsamen Nenner der Query-DSL beschraenken und regelmaessig gegen beide Zielsysteme testen, statt sich auf dauerhafte API-Identitaet zu verlassen.

# Separate, product-specific client libraries since the fork
pip install elasticsearch      # official Elasticsearch Python client
pip install opensearch-py      # official OpenSearch Python client

# Both expose a similar surface, but version pinning matters:
# elasticsearch==8.x targets Elasticsearch 8.x servers only
# opensearch-py targets OpenSearch clusters, compatibility with
# Elasticsearch servers of the same era is not guaranteed

8. Migrationsueberlegungen: wann sich ein Wechsel lohnt

Eine Migration von Elasticsearch zu OpenSearch oder umgekehrt ist technisch grundsaetzlich machbar, aber nicht trivial, weil kein direkter Rolling-Upgrade-Pfad zwischen den Systemen existiert. In der Praxis bedeutet ein Wechsel: Daten per Reindex oder Snapshot-Restore-Verfahren in den neuen Cluster ueberfuehren, alle genutzten Query-DSL-Konstrukte auf Kompatibilitaet pruefen, Dashboards und Alerting-Regeln manuell nachbauen, und Client-Bibliotheken im Anwendungscode austauschen.

Der Aufwand lohnt sich vor allem dann, wenn Lizenzfragen fuer das eigene Geschaeftsmodell direkt relevant sind, etwa weil ein Unternehmen selbst eine gehostete Suchloesung fuer Dritte anbietet, oder wenn die Kostenstruktur eines Managed-Services den Ausschlag gibt, etwa durch guenstigere OpenSearch-Angebote bei Cloud-Anbietern. Fuer reine interne Nutzung ohne Weiterverkauf ist der Migrationsaufwand oft groesser als der tatsaechliche Nutzen, insbesondere wenn der bestehende Cluster stabil laeuft und keine akuten Lizenzkonflikte bestehen.

# Typical migration path: snapshot on the source, restore on the target
# 1. Register a shared S3 repository readable by both clusters
# 2. Snapshot indices on the source cluster
curl -s -X PUT "https://source-cluster:9200/_snapshot/shared_repo/migration-2026-07-24" \
  -u elastic:changeme

# 3. Restore into the target cluster from the same repository
curl -s -X POST "https://target-cluster:9200/_snapshot/shared_repo/migration-2026-07-24/_restore" \
  -u admin:changeme

# 4. Validate document counts and sample queries before cutover
curl -s "https://target-cluster:9200/_cat/count/products?v" -u admin:changeme

9. Entscheidungskriterien fuer neue Projekte

Bei einem komplett neuen Projekt ohne bestehende Altlasten faellt die Entscheidung leichter, weil kein Migrationsaufwand anfaellt. Fuer Projekte, bei denen eine unstrittige, permissive Open-Source-Lizenz eine harte Anforderung ist, spricht viel fuer OpenSearch mit seiner konsequenten Apache-2.0-Lizenzierung. Fuer Projekte, bei denen die fortschrittlichsten ML- und Vektorsuche-Features den Ausschlag geben, oder bei denen bereits umfangreiches Elastic-Stack-Know-how im Team vorhanden ist, spricht vieles fuer Elasticsearch trotz der komplexeren Lizenzsituation.

Ein praktischer Test vor der endgueltigen Entscheidung: Beide Systeme mit einem realistischen Teil-Datensatz und den tatsaechlich benoetigten Queries in einer Testumgebung parallel betreiben, Performance, Ressourcenverbrauch und die Reife der jeweils benoetigten Spezialfunktionen direkt vergleichen. Diese praktische Evaluation liefert oft belastbarere Entscheidungsgrundlagen als eine rein theoretische Feature-Liste, weil sich Unterschiede in Detail-Verhalten von Aggregationen, Relevance-Scoring oder Cluster-Stabilitaet erst im echten Betrieb zeigen.

10. Zusammenfassung

Der Fork von 2021 hat aus einem gemeinsamen Codestand zwei eigenstaendige Projekte gemacht: Elasticsearch mit dualer beziehungsweise mittlerweile dreifacher Lizenzierung unter der Kontrolle von Elastic N.V., und OpenSearch unter durchgaengiger Apache-2.0-Lizenz und Foundation-Governance. Beide Systeme teilen weiterhin die Lucene-Basis und aehnliche Kernkonzepte, haben sich aber bei Vektorsuche, Security-Funktionsumfang, Dashboard-Tools und API-Details zunehmend auseinanderentwickelt.

Die richtige Wahl zwischen Elasticsearch und OpenSearch haengt weniger von einer pauschalen technischen Ueberlegenheit ab als von konkreten Anforderungen: Lizenzrestriktionen fuer das eigene Geschaeftsmodell, Bedarf an spezifischen ML-Features, vorhandenes Team-Know-how und die Kostenstruktur des bevorzugten Cloud-Anbieters. Eine praktische Evaluation mit echten Daten und Queries bleibt der zuverlaessigste Weg zu einer fundierten Entscheidung.

11. FAQ: Elasticsearch vs. OpenSearch