Elasticsearch vs. OpenSearch: der Fork, die Lizenzen, die Entscheidung

Elasticsearch und OpenSearch haben dieselbe Wurzel: die Java-Suchbibliothek Apache Lucene. OpenSearch ist ein Fork von Elasticsearch in Version 7.10.2 – im Jahr 2021 waren beide praktisch identisch. Wer heute zwischen ihnen wählt, vergleicht also keine fremden Produkte, sondern zwei Zweige desselben Baums.

Trotzdem ist die Entscheidung seitdem schwieriger geworden, nicht leichter. Der eigentliche Unterschied liegt kaum in den Features: Er liegt in der Lizenz, in der Governance und in der Frage, wem du die nächsten fünf Jahre deiner Suchinfrastruktur anvertraust. Deshalb schreibe ich diesen Artikel für Entscheider, nicht für Cluster-Administratoren.

Warum das wichtig ist: Eine Suchinfrastruktur tauschst du nicht nebenbei aus. Indizes, Abfragen, Dashboards und Betriebswissen wachsen über Jahre – ein erzwungener Wechsel kostet erfahrungsgemäß Wochen bis Monate Projektarbeit. Die Lizenzgeschichte beider Projekte zeigt dir, wie wahrscheinlich so ein Wechsel wird.

Ich gehe vier Dinge durch: die exakte Lizenz-Chronik mit allen vier Daten, die Frage, was Elastics «Open Source again» wirklich bedeutet, die belegbaren Unterschiede seit dem Fork und drei typische Ausgangslagen mit jeweils einer klaren Empfehlung. Am Ende steht die ehrlichste Option von allen: dass du vielleicht keinen der beiden brauchst.

Vorab zur Einordnung: Dieser Vergleich hilft dir auch dann, wenn gerade ein Angebot einer Agentur oder eines Cloud-Anbieters auf deinem Tisch liegt. Ein Satz fasst die ganze Entscheidung zusammen:

Viele Vergleichsartikel erzählen diese Geschichte ungenau oder verwechseln sogar die Jahreszahlen. Die Chronik ist aber der Kern der Entscheidung, weil sie zeigt, wie beide Seiten unter Druck handeln. Alle vier Daten habe ich am 04.09.2026 an den Primärquellen geprüft.

14. Januar 2021: Elastic kündigt an, Elasticsearch und Kibana ab Version 7.11 nicht mehr unter Apache 2.0 zu veröffentlichen, sondern unter SSPL und Elastic License (elastic.co, Blogpost vom 14.01.2021). Der Auslöser: Amazon verkaufte Elasticsearch jahrelang als Managed Service, ohne dass Elastic daran verdiente.

Die SSPL verpflichtet jeden, der die Software als Service anbietet, den Code seines gesamten Service-Stacks offenzulegen – für Cloud-Anbieter praktisch unbrauchbar. Genau das war der Zweck: AWS sollte Elasticsearch nicht länger ohne Gegenleistung monetarisieren können.

21. Januar 2021: AWS antwortet eine Woche später mit der Ankündigung eines Forks unter Apache 2.0, auf Basis der letzten Apache-2.0-Version 7.10 (aws.amazon.com, Open-Source-Blog, 21.01.2021). Der fertige Fork setzt konkret auf Elasticsearch 7.10.2 auf (opensearch.org, FAQ). Aus Sicht von AWS war der Lizenzwechsel ein Bruch mit der Open-Source-Community; aus Sicht von Elastic Notwehr gegen einen Hyperscaler.

Juli 2021: OpenSearch 1.0 erscheint als produktionsreifes Release (opensearch.org, FAQ, Abruf 04.09.2026). Ab hier existieren zwei Engines mit gemeinsamer Herkunft, aber getrennten Roadmaps – und jedes Team musste sich entscheiden, welchem Zweig es folgt.

29. August 2024: Elastic-Gründer Shay Banon verkündet «Elasticsearch is open source again»: Die AGPLv3 kommt als dritte Lizenzoption hinzu. Sein Wortlaut ist wichtig: Elastic ergänze nur eine Option («adding another option, and not removing anything») – SSPL und Elastic License 2.0 bleiben bestehen (elastic.co, 29.08.2024).

16. September 2024: Die Linux Foundation gründet die OpenSearch Software Foundation, und AWS überträgt ihr das Projekt. Premier-Mitglieder sind neben AWS auch SAP und Uber (linuxfoundation.org, Pressemitteilung vom 16.09.2024). OpenSearch gehört seitdem keinem einzelnen Hersteller mehr.

Für dich steckt in diesen vier Daten das ganze Muster. Elasticsearch bleibt das Produkt einer börsennotierten Firma, die ihre Lizenz binnen vier Jahren zweimal strategisch geändert hat: einmal restriktiver, einmal offener. OpenSearch ist seit 2024 ein Foundation-Projekt mit mehreren zahlenden Großunternehmen im Rücken. Beides kann für dich passen – aber es sind zwei verschiedene Weltbilder.

Die Schlagzeile von 2024 klingt nach vollständiger Rückkehr zu Open Source. Ein zweiter Blick lohnt sich: Laut Elastics eigener Lizenz-FAQ deckt die AGPLv3 «a significant portion of the source code» ab, wirksam ab etwa Release 8.16 Ende 2024 (elastic.co/pricing/faq/licensing, Abruf 04.09.2026). Der Quellcode ist damit zu großen Teilen wieder Open Source.

Das Standard-Binary ist es nicht. Elastics Download-Seite formuliert selbst: «This default distribution is governed by the Elastic License» (elastic.co/downloads/elasticsearch, Abruf 04.09.2026). Konkret heißt das: Wer das normale Elasticsearch-Paket herunterlädt und installiert, nutzt die Elastic License 2.0, nicht die AGPL. Diese Nuance fehlt in fast jedem Vergleichsartikel.

Bei OpenSearch ist die Lage schlicht: ein Binary, Apache 2.0, keine Ausnahmen. Die FAQ erlaubt ausdrücklich «use, modify, extend, monetize, and resell» (opensearch.org, Abruf 04.09.2026). Deine Rechtsabteilung prüft das in einer Viertelstunde.

Handfest wird der Unterschied beim Feature-Gating. Bei Elastic sind SSO via SAML und LDAP, Field- und Document-Level-Security, ML-Anomalieerkennung, Searchable Snapshots und Cross-Cluster-Replication kostenpflichtigen Stufen vorbehalten: Die freie Basic-Stufe bietet nur Datei- und native Authentifizierung (elastic.co/subscriptions, Abruf 04.09.2026). Bei OpenSearch steckt all das im Apache-2.0-Paket – ohne Aufpreis.

Heißt das, Elastic sei unseriös? Nein: Das Unternehmen finanziert so seine Entwicklung, und die Lizenz-FAQ legt die Bedingungen offen. Aber du solltest diese Details kennen, bevor du «Elasticsearch ist wieder Open Source» in eine Entscheidungsvorlage schreibst.

Seit 2021 entwickeln sich beide Projekte auseinander. Stand 04.09.2026 steht Elasticsearch bei Version 9.5.3 (Release vom 03.09.2026), OpenSearch bei 3.8.0 – beide Angaben stammen von den offiziellen Download-Seiten. Die gemeinsame Codebasis von damals verbindet sie noch, die Roadmaps trennen sie zunehmend.

Ein belegbares Beispiel sind die Abfragesprachen. Elastic hat mit ES|QL eine eigene, produktionsreife Query-Sprache entwickelt (elastic.co, Dokumentation). OpenSearch setzt stattdessen auf PPL und SQL. Für dich bedeutet das: Abfragen und Dashboards sind zwischen beiden Systemen nicht mehr einfach portierbar – der Fork wird mit jedem Jahr teurer zu überqueren.

In die Vektorsuche investieren dagegen beide sichtbar: Sie taucht in beiden Benchmark-Sets als eigene Disziplin auf und ist die technische Grundlage für KI-gestützte Suche. Was semantische Suche im Alltag bringt und wo ihre Grenzen liegen, behandle ich in einem eigenen Artikel.

Zur Performance kursieren zwei Zahlensätze, und bei beiden solltest du wissen, wer sie bezahlt hat. Der Sicherheitsdienstleister Trail of Bits hat im März 2025 OpenSearch 2.17.1 gegen Elasticsearch 8.15.4 gemessen – beauftragt von AWS, was der Bericht selbst offenlegt (blog.trailofbits.com, 06.03.2025).

Das Ergebnis ist gemischt: OpenSearch war im Big5-Workload 1,6-mal schneller und lag bei der Vektorsuche 11 Prozent vorn. Elasticsearch war dafür bei Text-Queries 2,42-mal schneller, und OpenSearch zeigte extremere Latenz-Ausreißer: im Maximum das 1412-Fache der Median-Latenz, gegenüber Faktor 43 bei Elasticsearch.

Elastic hält mit einem Eigenbenchmark dagegen: insgesamt 40 bis 140 Prozent schneller, bei Vektorsuche Faktor 2 bis 12 (elastic.co Search Labs, Vendor-Angabe, Abruf 04.09.2026). Beide Messungen basieren auf Versionsständen von Ende 2024 und sind damit Momentaufnahmen.

Meine ehrliche Lesart: Es gibt keine Performance-Krone. Je nach Workload gewinnt mal die eine, mal die andere Engine – und beide Zahlensätze stammen von Parteien mit wirtschaftlichem Interesse am Ergebnis. Triff die Entscheidung deshalb nicht über Benchmarks, sondern über Lizenz, Governance und dein Betriebsmodell.

Statt einer Feature-Tabelle mit vierzig Zeilen helfen dir drei Fragen: Wo läuft deine Infrastruktur, wer betreibt den Cluster, und was ist bereits im Einsatz? In meinen Projekten läuft die Entscheidung fast immer auf eine von drei Ausgangslagen hinaus.

Du bist im AWS-Ökosystem: Nimm OpenSearch. Der Amazon OpenSearch Service fügt sich in deine bestehende Umgebung ein, die Abrechnung läuft über deinen AWS-Vertrag, und die Projekt-Governance liegt bei einer Foundation, in der AWS Premier-Mitglied ist. Ein separater Elastic-Vertrag wäre ein zweiter Anbieter ohne zwingenden Grund.

Du hostest selbst und achtest auf Lizenz-Compliance: Auch hier spricht das meiste für OpenSearch. Apache 2.0 ist die unkomplizierteste Lizenz, die deine Rechtsabteilung je prüfen wird, Security-Features wie SSO kosten nichts extra, und seit der Foundation-Übergabe hängt das Projekt nicht mehr an den Interessen eines einzelnen Anbieters.

Du bist Elastic-Bestandskunde: Dann lohnt Bleiben meistens. Kibana, der Observability- und Security-Stack und ES|QL sind ausgereift, dein Team kennt das System, und eine Migration kostet Wochen bis Monate ohne fachlichen Mehrwert. Der AGPL-Schritt von 2024 hat zudem das Reputationsthema «proprietäre Lizenz» entschärft.

Ehrlich ergänzt: Es gibt auch Gründe, aktiv zu Elastic zu wechseln – etwa wenn du ES|QL oder Elastic Cloud als Managed-Angebot außerhalb von AWS willst. Nur der Reflex «Open Source gleich OpenSearch, kommerziell gleich Elastic» ist zu einfach: Beide Anbieter verdienen Geld mit dir, nur auf unterschiedlichen Wegen.

Zur Einordnung aus EU-Sicht: Beide Engines kannst du vollständig auf eigener oder europäischer Infrastruktur betreiben. Deine Datenhoheit hängt deshalb nicht am Fork, sondern am Betriebsmodell: Self-Hosting oder ein EU-Anbieter statt US-SaaS ist die eigentliche Weiche. Dieselbe Frage stellt sich übrigens bei Datenbank und Backend genauso.

Bevor du Cluster-Größen kalkulierst, stell die Frage eine Ebene höher: Brauchst du überhaupt eine dieser beiden Engines? Beide sind für Log-Analytics, Observability und Suche über sehr große Datenmengen gebaut. Für die Suchfunktion einer Website oder eines Shops sind sie fast immer überdimensioniert – auch dann, wenn ein Dienstleister dir reflexhaft einen Cluster anbietet.

Meine Reihenfolge in Projekten: Erst prüfe ich, ob die Postgres-Volltextsuche reicht – sie steckt in der Datenbank, die du ohnehin betreibst. Für Instant Search mit Facetten und Tippfehler-Toleranz ist Meilisearch der pragmatische Mittelweg: MIT-lizenzierter Kern plus separat lizenzierte Enterprise-Module, self-hostbar, in einem Nachmittag aufgesetzt. Elasticsearch oder OpenSearch kommen erst ins Spiel, wenn Analytics und Datenvolumen es erzwingen.

Das ganze Feld jenseits der beiden großen Engines habe ich im Artikel über Elasticsearch-Alternativen sortiert: von der Postgres-Stufe bis zu den leichtgewichtigen Engines. Und wie du die Suchfunktion deiner Website Schritt für Schritt verbesserst, zeigt dir der praktische Einstiegsartikel dieser Serie. Beide Artikel nehmen dir die Vorarbeit ab, bevor du überhaupt ein Cluster-Angebot einholst.

Wenn du vor genau dieser Entscheidung stehst, kläre zuerst die Governance- und Lizenzfrage für dein Betriebsmodell und erst danach die Features. Die vier Daten der Chronik und die Binary-Nuance aus diesem Artikel reichen aus, um jedem Anbieter und jeder Agentur die richtigen Fragen zu stellen. Diese Reihenfolge schützt dich vor der teuersten Fehlentscheidung: einem Migrationsprojekt, das eigentlich ein Lizenzproblem war.

Was du heute schon tun kannst: Prüfe, unter welcher Lizenz dein aktueller Cluster läuft und welche der bezahlten Features dein Team tatsächlich nutzt. Erfahrungsgemäß zahlen viele Teams für Stufen, deren Funktionen sie nie angefasst haben – oder betreiben einen Cluster für eine Last, die eine kleinere Lösung längst tragen könnte.

Ich helfe dir bei der Einordnung: von der ehrlichen Prüfung, ob Postgres oder Meilisearch für deinen Fall reichen, bis zum Betriebskonzept für einen OpenSearch-Cluster auf europäischer Infrastruktur. Buch dir ein kostenloses Erstgespräch – in 30 Minuten schauen wir uns deine Ausgangslage an, und du gehst mit einer klaren Empfehlung raus.