„Das Ende ist nah." Mit diesem Satz habe ich vor Jahren schon einmal über das End of Life von MySQL 5.6 geschrieben (vgl. https://blog.ordix.de/was-passiert-mit-der-community-edition-oracle-mysql). Jetzt trifft es 8.0. Im April 2026 hat Oracle mit Version 8.0.46 den Support beendet. Wer noch produktive 8.0-Instanzen betreibt, ist spätestens jetzt im Handlungsmodus.
Parallel dazu ist mit MySQL 9.7.0 das neue Long-Term-Support-Release erschienen. Ein guter Anlass, beides zusammen anzuschauen. Ehrlich gesagt ist es auch ein Anlass, über den allgemeinen Zustand von MySQL als Open-Source-Projekt zu sprechen.
Was 9.7 für die Community-Edition bringt
Ich konzentriere mich bewusst auf die Community-Edition. Die Enterprise-Variante lasse ich, wie immer, weitgehend außen vor.
Fangen wir mit dem Positiven an. Oracle hat mehrere Funktionen, die bisher Enterprise-Kunden vorbehalten waren, in die Community-Edition übernommen. Darunter vier Replikations-Komponenten, die im Alltag tatsächlich einen Unterschied machen.
Wer schon einmal versucht hat, den Replikations-Lag in einem Group-Replication- oder InnoDB-Cluster-Umfeld sauber einzustellen, kennt die Mühe. „Replication Applier Metrics” und „Group Replication Flow Control Statistics” setzen genau hier an. Endlich auch in der Community-Edition. Das ist kein kosmetisches Update, sondern eines, das im Betrieb spürbar wird.
Ebenfalls neu: JSON Duality Views unterstützen jetzt vollständig DML. Bisher waren diese Views nur lesend nutzbar. Mit 9.7 funktionieren nun auch INSERT, UPDATE und DELETE. Ob man Duality Views im eigenen Stack sinnvoll einsetzen kann, ist eine eigene Diskussion. Die Lücke zwischen Community- und Enterprise-Version schließt sich an dieser Stelle aber wieder ein Stück.
Spannend finde ich den Hypergraph Optimizer. Ein neuer Ansatz zur Query-Optimierung, der bei komplexen Joins über viele Tabellen deutlich bessere Ausführungspläne erzeugen soll. Peter Zaitsev, Gründer von Percona, hat dazu eine klare Position: testen, testen, testen. Dem schließe ich mich an. Ein neuer Optimizer bedeutet nicht automatisch bessere Performance für den eigenen Workload. Manchmal eher das Gegenteil.
Auf der Sicherheitsseite wurden die Hashing-Optionen für caching_sha2_password gestärkt (PBKDF2 mit SHA-512). Für regulierte Umgebungen wie PCI-DSS oder DORA ist das ein relevantes Detail. Hinzu kommen OpenID-Authentifizierung und neue Systemvariablen zur feineren Replikationssteuerung.
Der Upgrade-Pfad
Ein direktes Upgrade von 8.0 auf 9.7 ist nicht vorgesehen. Der Weg führt über 8.4 LTS. Wer den MySQL Upgrade Checker noch nicht im Werkzeugkasten hat: In meinem Beitrag „Kurz und gut, Episode #21” habe ich beschrieben, wie das Tool funktioniert. Es identifiziert Inkompatibilitäten frühzeitig. Und davon gibt es zwischen 8.0 und 8.4 einige, etwa rund um entfernte Authentifizierungs-Plugins.
Für 9.7 verspricht Oracle 5 Jahre Premier Support und 3 Jahre Extended Support. Damit kauft man sich wieder Planungssicherheit für die nächsten Jahre.
Der unbequeme Teil
2024 habe ich unter dem Titel „Quo Vadis?” meine Bedenken zur Entwicklung der MySQL-Community-Edition beschrieben. Stand heute haben sich diese Bedenken nicht aufgelöst. Manches ist sogar dazugekommen.
Die aktive Contributor-Basis des Projekts liegt laut einer Percona-Analyse in Q3 2025 bei rund 75 Personen. 2017 waren es etwa 135. Die Zahl der jährlichen Commits im öffentlichen Repository ist parallel deutlich zurückgegangen. Dazu kommen Meldungen über Stellenstreichungen im MySQL-Team bei Oracle. Frederic Descamps, langjähriger Community-Manager und für viele in der Szene ein Gesicht des Projekts, ist zur MariaDB Foundation gewechselt.
Das sind in Summe keine Randnotizen.
Community-Benchmarks, etwa von Mark Callaghan, zeigen außerdem, dass schreiblastige Workloads in neueren MySQL-Versionen teilweise schlechter abschneiden als in 8.0. Wichtig: Das sind Messungen aus der Community, keine offiziellen Zahlen von Oracle. Aber sie reichen, um beim Upgrade nicht blind zu vertrauen, sondern in der eigenen Umgebung gegenzumessen.
Ein Punkt beschäftigt mich seit 2024 besonders. Im KI-Umfeld fehlen der Community-Edition zentrale Funktionen. Vektordaten und Vektorsuche, in PostgreSQL und MariaDB längst etabliert, gibt es bei MySQL bisher nur in HeatWave, also in der proprietären Oracle-Cloud-Welt. Datenbanken sind im Aufbau moderner KI-Architekturen kein Beiwerk, sondern oft das Rückgrat. Eine Open-Source-Datenbank, die hier nicht mitzieht, verliert an Relevanz. Schleichend, aber sicher.
Fazit: Was heißt das praktisch?
Wer noch 8.0 produktiv betreibt: Migration einplanen, jetzt. Der Aufschub ist vorbei. Mein Vorschlag: 8.4 LTS als Zwischenstation, dann mittelfristig 9.7 LTS.
Wer ohnehin gerade die Datenbank-Strategie auf den Tisch legt, sollte den Blick weiten. MariaDB, Percona Server for MySQL und PostgreSQL sind ernstzunehmende Alternativen. Je nach Anforderungsprofil und, das ist mir persönlich wichtig, je nachdem, welchen Stellenwert Open-Source-Governance in der eigenen Entscheidung hat.
MySQL gehört nach wie vor zu den Datenbanken, mit denen ich täglich arbeite. Aber ich wäre nicht ehrlich, wenn ich behaupten würde, dass mich die Entwicklungen der letzten zwei Jahre kaltlassen. Ich hoffe, dass 9.7 mehr ist als ein gut platziertes Signal. Sehen werden wir es in den nächsten Releases.
Fragen zum Betrieb von MySQL, MariaDB oder Percona-Server? Sprecht mich gerne an.
Quellen
Contributor-Zahlen: Percona-Analyse, zitiert in InfoQ (Dezember 2025)
Performance-Vergleiche: Community-Benchmarks von Mark Callaghan – keine offiziellen Oracle-Messungen
Wechsel Frederic Descamps zur MariaDB Foundation: CIO und InfoWorld (Februar 2026)
Oracle MySQL 9.7.0 Release Notes (April 2026)
Seminarempfehlung
MYSQL ADMINISTRATION DB-MY-01
Mehr erfahren