End of Life Datenbank: Was passiert wenn MySQL oder PostgreSQL EOL erreicht
Ihre Datenbank läuft seit Jahren zuverlässig. MySQL 5.7 oder eine ältere PostgreSQL-Version verrichtet im Hintergrund ihren Dienst, ohne dass jemand genauer hinschaut. Das Problem dabei: MySQL End of Life bedeutet nicht, dass die Software aufhört zu funktionieren. Sie läuft weiter, nur ohne Sicherheits-Updates. Für Angreifer ist das ein offenes Tor. Für Ihr Unternehmen ein Risiko, das mit jedem Monat wächst, den niemand hinschaut.
Dieser Artikel erklärt, welche Datenbankversionen aktuell End of Life sind, welche Risiken dadurch entstehen und wie ein sicherer Weg zu einer unterstützten Version aussieht.
Was bedeutet End of Life bei einer Datenbank?
Jede Datenbank-Software durchläuft einen Lebenszyklus. Am Anfang liefert der Hersteller neue Funktionen und Fehlerkorrekturen. Später gibt es nur noch Sicherheits-Updates. Irgendwann endet auch das. Dieser letzte Punkt heißt End of Life, kurz EOL. Ab diesem Zeitpunkt schließt niemand mehr neu entdeckte Sicherheitslücken. Die Software bleibt technisch stehen, während neue Angriffsmethoden weiterentwickelt werden.
Die Begriffe End of Life, End of Support und End of Maintenance werden oft synonym verwendet, meinen aber nicht immer dasselbe. Was genau der Unterschied ist, erklären wir in unserem Artikel End of Life, End of Support und End of Maintenance im Vergleich.
Welche Datenbankversionen sind aktuell betroffen?
MySQL 5.6 und MySQL 5.7 haben ihr End of Life bereits erreicht. Die Details dazu, was das konkret für Ihre Datenbank bedeutet, haben wir in einem eigenen Artikel zusammengefasst: MySQL 5 End of Life: Was Ihre Datenbank betrifft. MySQL 8.0 wird zum jetzigen Zeitpunkt noch gepflegt, ihr Support-Ende rückt aber näher.
Bei PostgreSQL sieht der Lebenszyklus anders aus. Jede Hauptversion erhält für gewöhnlich fünf Jahre lang Sicherheits-Updates, danach endet der Support. Wer eine Version betreibt, die vor mehr als fünf Jahren veröffentlicht wurde, arbeitet heute ohne Sicherheitsnetz. Welche Support-Zeiträume für welche Software gelten und wie sich das von kommerziellen Long-Term-Support-Modellen unterscheidet, lesen Sie in unserem Artikel Long Term Support einfach erklärt.
Auch die laufende Betreuung wird mit der Zeit schwieriger. Externe Tools, Treiber und Bibliotheken setzen zunehmend aktuelle Datenbankversionen voraus. Wie sich die Wartung älterer MySQL-Versionen in der Praxis gestaltet und wo die Grenzen liegen, zeigt unser vertiefender Artikel dazu.
Welche Risiken entstehen wenn eine Datenbank EOL erreicht?
Sicherheitslücken ohne Patches
Datenbanken speichern die wertvollsten Daten eines Unternehmens: Kundendaten, Bestellungen, Zugangsdaten, oft auch Zahlungsinformationen. Eine Sicherheitslücke in einer EOL-Datenbank wird nicht mehr geschlossen. Neue CVEs, also öffentlich dokumentierte Sicherheitslücken, tauchen weiterhin auf, nur eben ohne Korrektur. Angreifer scannen das Internet automatisiert nach Systemen mit bekannten, offenen Lücken. Eine veraltete Datenbank ist dabei ein leicht zu findendes Ziel.
Kompatibilitätsprobleme mit neuer Software
Neue Anwendungen, Frameworks und Bibliotheken setzen zunehmend aktuelle Datenbankversionen voraus. Wer an einer alten Version festhält, kann irgendwann keine neuen Funktionen mehr integrieren, ohne vorher ein Upgrade durchzuführen. Auch Hosting-Anbieter stellen den Support für alte Datenbankversionen früher oder später ein. Dann bleibt nur ein Wechsel des Anbieters oder das Upgrade, oft unter Zeitdruck.
DSGVO-Risiken durch fehlenden Schutz
Die Datenschutz-Grundverordnung verlangt einen angemessenen technischen Schutz personenbezogener Daten. Eine Datenbank ohne Sicherheits-Updates erfüllt diesen Anspruch nicht mehr. Kommt es zu einem Datenschutzvorfall, prüft eine Aufsichtsbehörde genau, ob die eingesetzte Software zum Zeitpunkt des Vorfalls noch unterstützt wurde. Eine überzeugende Antwort gibt es darauf bei einer EOL-Datenbank nicht.
Wie sieht ein sicherer Upgrade-Pfad aus?
Ein Datenbank-Upgrade betrifft nicht nur die Software selbst. Anwendungen, Abfragen und Zugriffsrechte müssen mitziehen. Wer das unterschätzt, riskiert Datenverlust oder tagelange Ausfälle. Mit einem strukturierten Vorgehen lässt sich das Risiko deutlich reduzieren.
Schritt 1: Bestandsaufnahme
Zuerst muss klar sein, womit man es zu tun hat. Welche Version läuft aktuell? Welche Anwendungen greifen auf die Datenbank zu? Welche Abfragen nutzen Funktionen, die in neueren Versionen entfernt oder verändert wurden? Diese Fragen lassen sich mit den richtigen Werkzeugen weitgehend automatisiert beantworten.
Schritt 2: Testumgebung und Testlauf
Kein Upgrade findet direkt in der Produktivumgebung statt. Auf einer Kopie der Datenbank wird das Upgrade zuerst durchgeführt und ausführlich getestet. Fehlerhafte Abfragen und inkompatible Funktionen fallen hier auf, bevor sie echten Schaden anrichten.
Schritt 3: Migration mit Backup
Erst wenn der Testlauf fehlerfrei durchläuft, geht es in die Produktivumgebung. Vor jedem Schritt steht ein vollständiges Backup. So bleibt im Ernstfall ein Weg zurück zur alten Version offen.
Schritt 4: Monitoring nach dem Upgrade
Nach der Migration werden Fehlerprotokolle und Performance in den ersten Tagen genau beobachtet. Ungewöhnliches Verhalten fällt so früh auf und lässt sich schnell beheben, statt sich unbemerkt festzusetzen.
Was kostet ein Datenbank-Upgrade und wie lange dauert es?
Die Kosten hängen stark von der Systemgröße und dem Alter der Anwendung ab. Ein kleines System mit wenigen Tabellen und einer überschaubaren Anwendung lässt sich oft in ein bis zwei Tagen migrieren. Ein gewachsenes System mit individuellem Code, alten Abfragen und fehlender Dokumentation braucht deutlich mehr Zeit, mitunter mehrere Wochen.
Eine seriöse Einschätzung gibt es erst nach einer Analyse des konkreten Systems. Pauschale Preise ohne diesen Blick sind selten belastbar. Wir führen diese Analyse durch und liefern eine reale Aufwandsschätzung, bevor überhaupt ein Auftrag zustande kommt.
Warum jetzt handeln statt abwarten?
Viele Unternehmen schieben die Datenbank-Migration auf, weil das laufende Tagesgeschäft dazwischenkommt und die Datenbank ja funktioniert. Das ist menschlich, aber riskant. Jeder Monat auf einer EOL-Datenbank erhöht die Zahl der bekannten, ungeschlossenen Lücken. Gleichzeitig wächst der Datenbestand weiter, was eine spätere Migration aufwendiger macht als eine frühzeitige.
Hinzu kommt: Ein Upgrade unter Zeitdruck, etwa weil ein Hosting-Anbieter den Support kurzfristig einstellt, lässt sich selten sauber planen. Wer jetzt startet, kann Schritte in Ruhe testen, Rückschläge einkalkulieren und den Zeitpunkt selbst bestimmen. Wer wartet, überlässt diese Entscheidung irgendwann anderen.
Fazit: Warten macht die Migration nicht billiger
MySQL End of Life und das Support-Ende bei PostgreSQL sind keine Randnotiz für die IT-Abteilung. Sie betreffen den Kern jedes Unternehmens: die eigenen Daten. Je länger eine Datenbank ohne Updates läuft, desto teurer wird die spätere Migration und desto größer das Risiko in der Zwischenzeit.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Datenbank an und sagen Ihnen ehrlich, wo Sie stehen und was als nächstes sinnvoll ist.
