Oracle hat MySQL in eine proprietäre Cloud-Strategie eingebettet, die Interessen der Open-Source-Community dabei systematisch hintenangestellt und den Fokus längst auf bezahlpflichtige Dienste verlagert. Es gibt eine bessere Alternative – und der Erfinder von MySQL nutzt sie selbst.
1. Wie Oracle MySQL übernahm – und was danach passierte
MySQL wurde 1995 als freie Software entwickelt und wurde schnell zum Rückgrat des frühen Webs – als Teil des berühmten LAMP-Stacks (Linux, Apache, MySQL, PHP/Perl/Python). Kostenlos, schnell, zuverlässig, offen. Ein Paradebeispiel dafür, was Open-Source-Software leisten kann.
2008 kaufte Sun Microsystems MySQL. Sun hatte gute Absichten – aber 2010 schluckte Oracle Sun, und damit auch MySQL. Das war der Moment, an dem sich die Weichen stellten. Oracle ist kein Open-Source-Unternehmen. Oracle ist ein Datenbankkonzern, dessen Kerngeschäft seit Jahrzehnten proprietäre Enterprise-Datenbanken sind. MySQL war für Oracle von Anfang an vor allem eines: ein potenzieller Wettbewerber zum eigenen Produkt, den man besser kontrolliert als frei lässt.
Was folgte, war kein spektakuläres Ereignis, sondern ein schleichender Prozess: Features wanderten in die kostenpflichtige Enterprise Edition. Die Entwicklungsgeschwindigkeit verlangsamte sich spürbar. Oracles Fokus verschob sich zunehmend auf MySQL HeatWave – eine proprietäre, ausschließlich Cloud-basierte Variante, die zwar auf MySQL basiert, aber nur gegen Bezahlung in Oracles eigener Cloud (und mittlerweile auch auf AWS und Azure) verfügbar ist.
Die Open-Source-Community bekam das zu spüren: Während HeatWave mit massiven Performance-Optimierungen und modernen Features beworben wird, hinkt die kostenfreie Community Edition hinterher. Das ist kein Zufall – es ist Geschäftsstrategie.
2. Monty Widenius: Der Erfinder stimmte mit den Füßen ab
Michael „Monty“ Widenius ist einer der Schöpfer von MySQL. Er hat das Projekt in den 1990ern miterfunden, jahrzehntelang geprägt und maßgeblich dafür gesorgt, dass MySQL zur meistgenutzten relationalen Open-Source-Datenbank der Welt wurde. MySQL ist nach seiner Tochter My benannt.
Und Widenius hat MySQL verlassen.
Noch bevor die Oracle-Übernahme abgeschlossen war, begann er mit der Arbeit an einem echten Community-Fork: MariaDB – benannt nach seiner Tochter Maria. Das war kein impulsiver Schritt und kein persönlicher Zwist. Es war eine klare strategische Entscheidung: Ein Datenbanksystem, dessen Schicksal in den Händen eines profitorientierten US-Großkonzerns liegt, ist kein verlässliches Fundament für kritische Infrastruktur.
Widenius hatte recht. In den folgenden Jahren bestätigte sich sein Misstrauen Schritt für Schritt. Oracle drängte immer stärker auf proprietäre Modelle, verlagerte Entwicklungsressourcen in Richtung Cloud-Profitabilität und verließ sich auf das Trägheitsmoment der bereits installierten MySQL-Basis – Millionen von Systemen, die schlicht weiterlaufen, weil niemand die Zeit für eine Migration findet.
Wenn der Mensch, der MySQL erfunden hat, sein eigenes Projekt verlässt und eine Alternative gründet, ist das kein Signal, das man ignorieren sollte. Es ist ein Urteil – gefällt von jemandem, der die Datenbank besser kennt als irgendjemand sonst.
3. HeatWave: Wenn Open Source zur Verkaufsmasche wird
MySQL HeatWave ist Oracles Antwort auf die Frage, wie man aus einer kostenlosen Open-Source-Datenbank ein profitables Cloud-Produkt macht. HeatWave ist technisch eindrucksvoll: eine massiv parallele, In-Memory-Query-Engine, die analytische Workloads erheblich beschleunigt und direkt in MySQL integriert ist. Oracle bewirbt Benchmarks, die HeatWave weit vor Amazon Redshift oder Snowflake positionieren.
Das Problem: All das gibt es nur in Oracles Cloud. Wer HeatWave nutzen will, zahlt Oracle für Cloud-Ressourcen – monatlich, wiederkehrend, ohne Ausstiegsoption ohne Datenmigration. Die Community Edition bekommt davon nichts, oder bestenfalls deutlich verzögerte Echos der Entwicklungsarbeit.
Das ist das eigentliche Geschäftsmodell: Die freie Community Edition hält die Nutzerbasis groß und senkt die Einstiegshürde. Der eigentliche Wert – Performance, Skalierbarkeit, moderne Features – wird in die Cloud-Version gepackt, für die man zahlt. Open Source wird hier zur Akquisestrategie, nicht zur Überzeugung.
Kritiker in der Datenbankwelt bezeichnen diesen Ansatz seit Jahren als „Open-Core-Falle“: Die Basis ist frei, aber alles Wichtige kostet. Das ist bei MySQL unter Oracle besonders offensichtlich, weil der Kontrast zwischen dem, was HeatWave kann, und dem, was die Community Edition bekommt, so deutlich ist.
4. Das Lizenzproblem: Was das CLA wirklich bedeutet
Die MySQL Community Edition ist unter der GPLv2 lizenziert – das stimmt, und es ist wichtig. Wer MySQL einsetzt, hat grundsätzlich keine Lizenzprobleme, solange er die GPL-Bedingungen einhält.
Aber es gibt einen Haken, der in der öffentlichen Diskussion zu selten erwähnt wird: das Contributor License Agreement (CLA). Wer Code zu MySQL beitragen will, muss dieses CLA unterzeichnen. Es gibt Oracle das Recht, Community-Beiträge nicht nur in die freie Community Edition aufzunehmen, sondern auch in die proprietäre Enterprise Edition und in HeatWave – ohne die Beitragsleistenden dafür zu vergüten oder um Erlaubnis zu fragen.
Das bedeutet in der Praxis: Die Entwicklungsarbeit der Community fließt direkt in Oracles Produkte ein, die Oracle dann verkauft. Die Community arbeitet kostenlos für den Konzern mit. Wer das weiß, versteht, warum viele erfahrene Entwickler ihre Energie lieber in MariaDB stecken, das eine echte Community-Governance durch die MariaDB Foundation hat – eine gemeinnützige Organisation ohne Konzerninteressen im Rücken.
5. MariaDB: Was es ist und warum es besser ist
MariaDB ist kein bloßes Imitat von MySQL. Es ist ein echter, von der Community getragener Fork mit eigenem Entwicklungsweg, eigener Governance und einer klaren philosophischen Aussage: Diese Datenbank gehört niemandem, der sie gegen die Interessen ihrer Nutzer einsetzen könnte.
Die MariaDB Foundation ist eine gemeinnützige Organisation, die die Weiterentwicklung koordiniert und sicherstellt, dass Entscheidungen im Interesse der Community getroffen werden – nicht im Interesse von Quartalsergebnissen. Zusätzlich gibt es die MariaDB Corporation, die kommerzielle Unterstützung und Enterprise-Features anbietet, aber keinen Einfluss auf den Community-Kern hat.
Technisch hat MariaDB in den vergangenen Jahren eine Reihe von Features entwickelt und früher implementiert als MySQL, darunter:
Temporal Tables nach SQL:2011-Standard – eingebaute Unterstützung für zeitbasierte Datenversionierung, die MySQL-Nutzer oft über Trigger oder Anwendungslogik nachbauen müssen.
Galera Cluster für echte Multi-Master-Replikation – nativ integriert und seit Jahren kampferprobt in Hochverfügbarkeitsumgebungen.
Aria Storage Engine als absturzsichere Alternative für interne Tabellen und temporäre Operationen.
ColumnStore für analytische Workloads und Data-Warehousing-Szenarien – direkt im Datenbankserver, ohne Cloud-Pflicht.
Hinzu kommt ein konsequent offener Entwicklungsprozess: Roadmap öffentlich, Bugs öffentlich, Diskussionen öffentlich. Keine Überraschungen, keine Features, die plötzlich hinter eine Enterprise-Schranke verschwinden.
6. MariaDB vs. MySQL: Die ehrlichen Unterschiede
Ein fairer Vergleich erfordert Ehrlichkeit in beide Richtungen. MySQL hat sich technisch weiterentwickelt – die Versionen 8.0, 8.4 und 9.x haben echte Verbesserungen gebracht. Wer behauptet, MySQL sei technisch stehen geblieben, liegt falsch.
Was jedoch stimmt: Die Entwicklungsprioritäten bei Oracle liegen klar bei HeatWave und der Cloud-Version. Die Community Edition profitiert davon nur indirekt und verzögert.
Drop-in-Kompatibilität: Hier ist Vorsicht geboten. Ältere Aussagen, dass MariaDB ein einfacher „Drop-in“-Ersatz für MySQL sei, gelten für moderne Versionen nur noch eingeschränkt. Seit MariaDB 10.x und MySQL 8.0 sind die internen Datenformate und bestimmte SQL-Erweiterungen der beiden Systeme auseinanderdriftet. Ein einfaches Austauschen der Binaries funktioniert bei aktuellen Versionen oft nicht mehr ohne manuelle Migration. Das muss man wissen, bevor man plant.
Lizenz: MariaDB ist vollständig unter GPL und LGPL lizenziert, ohne das problematische CLA von MySQL. Wer Code beiträgt, behält die Kontrolle darüber, dass sein Beitrag nicht heimlich in proprietäre Produkte fließt.
Governance: Das ist der eigentliche Kernunterschied. Bei MySQL entscheidet Oracle. Bei MariaDB entscheidet die Foundation gemeinsam mit der Community. Das klingt abstrakt – ist aber in der Praxis der Unterschied zwischen einem Projekt, das langfristig planbar ist, und einem Projekt, das jederzeit einem Strategieschwenk zum Opfer fallen kann.
Performance: In den meisten alltäglichen Workloads sind beide Systeme auf vergleichbarem Niveau. Für spezifische analytische Szenarien ist HeatWave deutlich schneller – aber eben nur in Oracles Cloud.
7. Wer setzt bereits auf MariaDB?
MariaDB ist keine Nischenlösung für überzeugte Open-Source-Aktivisten. Es ist eine bewährte, produktionsreife Datenbank im Einsatz bei einigen der größten Organisationen der Welt.
Wikipedia betreibt seine gesamte Datenbankinfrastruktur auf MariaDB. Red Hat Enterprise Linux und Fedora haben MySQL als Standard-Datenbankserver durch MariaDB ersetzt. Debian und viele andere Linux-Distributionen liefern MariaDB als bevorzugtes Paket aus. Große Hosting-Anbieter weltweit haben auf MariaDB umgestellt, weil es lizenzrechtlich unkomplizierter und governance-technisch verlässlicher ist.
Das ist kein ideologisches Statement dieser Organisationen. Das sind pragmatische Entscheidungen von Leuten, die kritische Infrastruktur betreiben und nicht von den Strategieschwenks eines US-Konzerns abhängig sein wollen.
8. Migration von MySQL zu MariaDB: Realistisch betrachtet
Hier ist Ehrlichkeit wichtiger als Optimismus. Eine Migration von aktuellen MySQL-Versionen (8.0, 8.4, 9.x) zu MariaDB (10.x, 11.x) ist kein trivialer Vorgang mehr. Die internen Datenformate sind inzwischen so weit auseinandergedriftet, dass ein einfaches Austauschen des Datenbankservers in den meisten Fällen nicht funktioniert.
Was eine Migration konkret erfordert:
Für ältere Systeme auf MySQL 5.7 oder früher ist der Aufwand überschaubar: Datenbank-Dump mit mysqldump erstellen, MariaDB installieren, Dump importieren, Anwendung testen. In vielen Fällen läuft das ohne weitere Anpassungen.
Für neuere MySQL-Versionen ist eine sorgfältige Prüfung nötig: Welche spezifischen MySQL-8.x-Features werden genutzt? Gibt es JSON-Funktionen, Window Functions oder andere Features, deren Implementierung in MariaDB abweicht? Die MariaDB-Dokumentation listet bekannte Inkompatibilitäten detailliert auf – diese Seiten sollte man vor jeder Migration gelesen haben.
Empfohlener Migrationsweg: Eine Parallel-Instanz mit MariaDB aufsetzen, die Anwendung vollständig dagegen testen, Abweichungen im Verhalten dokumentieren und beheben, erst dann produktiv umstellen. Das ist mehr Aufwand als ein einfacher Servertausch – aber es ist machbar, und es ist einmaliger Aufwand für langfristige Unabhängigkeit.
Für Neuinstallationen ist die Entscheidung dagegen einfach: Es gibt keinen vernünftigen Grund, heute noch eine neue Anwendung auf MySQL aufzubauen, wenn MariaDB zur Verfügung steht.
9. Digitale Souveränität beginnt bei der Datenbank
Die Debatte um digitale Souveränität wird häufig auf Betriebssysteme, Cloud-Plattformen und Bürosoftware verengt. Dabei liegt ein oft übersehener Knackpunkt tiefer in der Infrastruktur: die Datenbank.
Daten sind das Herzstück jeder Anwendung, jeder Behörde, jedes Unternehmens. Wer die Datenbank kontrolliert, kontrolliert den Zugang zu diesen Daten – ihre Verfügbarkeit, ihre Sicherheit, ihre Lizenzierung. Eine Datenbank, die einem US-amerikanischen Großkonzern gehört, der durch amerikanisches Recht verpflichtet werden kann, bestimmte Zugänge zu ermöglichen oder Features einzuschränken, ist kein souveränes Fundament.
Der CLOUD Act erlaubt US-Behörden unter bestimmten Bedingungen den Zugriff auf Daten amerikanischer Unternehmen – unabhängig davon, wo die Server physisch stehen. Wer seine Anwendung auf MySQL-HeatWave in Oracles Cloud betreibt, sitzt damit in einer doppelten Abhängigkeit: technisch an Oracle gebunden, rechtlich dem US-amerikanischen Recht ausgesetzt.
MariaDB bricht diese Abhängigkeit. Die MariaDB Foundation ist eine europäisch geprägte, gemeinnützige Organisation. Der Quellcode ist vollständig offen. Es gibt keine proprietären Ausnahmen, keine Enterprise-Fallen, keine Abhängigkeit von einem Konzern, der morgen seine Strategie ändern könnte. Wer MariaDB einsetzt, betreibt seine Datenbank unter Bedingungen, die er selbst kontrolliert.
10. Fazit: Vertrauen muss man sich verdienen
MySQL ist nicht tot. Es ist eine technisch funktionierende Datenbank mit einer riesigen installierten Basis und einer langen Geschichte. Wer heute MySQL betreibt und keine Probleme hat, wird nicht morgen früh aufwachen und feststellen, dass alles zusammengebrochen ist.
Aber Vertrauen in ein Infrastrukturprojekt bedeutet nicht, auf aktuelle Funktionsfähigkeit zu schauen. Es bedeutet, auf Strukturen zu schauen: Wem gehört das Projekt? Wer trifft die Entscheidungen? Was passiert, wenn die Interessen des Eigentümers und die Interessen der Community auseinandergehen?
Diese Fragen beantwortet MySQL unter Oracle strukturell zuungunsten der Community – durch das CLA, durch den HeatWave-Fokus, durch eine Governance, die keine echte Community-Kontrolle kennt. Und der Mensch, der MySQL erfunden hat, hat diese Schlussfolgerung bereits 2009 gezogen und MariaDB gegründet.
MariaDB ist technisch ausgereift, lizenzrechtlich sauber und governance-technisch unabhängig. Die Migration erfordert bei modernen Versionen sorgfältige Planung – aber sie ist machbar, und der Aufwand lohnt sich. Für Neuinstallationen gibt es heute keinen guten Grund mehr, zu MySQL zu greifen.
Die Frage ist nicht ob man langfristig von Oracle-kontrollierten Infrastrukturkomponenten wegkommen sollte. Die Frage ist nur, wann man anfängt.
