MariaDB 10.6 erreicht am 6. Juli 2026 das Ende der Lebensdauer: Was das bedeutet und wie Sie die Sicherheit gewährleisten können

Die wichtigsten Erkenntnisse

• MariaDB Community Server 10.6 erreicht am 6. Juli 2026 das Ende seines Lebenszyklus. Nach diesem Datum stellt das MariaDB-Projekt die Bereitstellung von Sicherheitspatches und Fehlerbehebungen für 10.6 ein.
• Der Betrieb einer nicht gepatchten Datenbank in der Produktionsumgebung stellt ein Sicherheits- und Compliance-Problem dar. PCI DSS, HIPAA, SOC 2 und FedRAMP verlangen alle die zeitnahe Behebung bekannter Sicherheitslücken.
• Ein Upgrade auf 11.4 oder 11.8 LTS ist langfristig die richtige Entscheidung, wenn es sich reibungslos durchführen lässt. Wenn der Zeitplan eng ist, bietet der TuxCare Endless Lifecycle Support für MariaDB sorgt dafür, dass 10.6 auf dem neuesten Stand bleibt, sodass Sie das Upgrade nach Ihrem eigenen Zeitplan durchführen können.

Wenn Sie MariaDB Community Server 10.6 in der Produktion einsetzen, sollten Sie sich dieses Datum im Kalender vormerken: 6. Juli 2026. An diesem Tag erreicht der 10.6-Zweig das Ende seiner Lebensdauer, und das MariaDB-Projekt schließt ihn. Danach stellt das Projekt die Veröffentlichung von Releases, Bugfixes und Sicherheitspatches für diesen Zweig ein.

Nach dem 6. Juli wird Ihre Datenbank Abfragen weiterhin genauso bearbeiten wie am Tag zuvor. Das Problem ist, was sich in den folgenden Monaten im Hintergrund abspielt: Es werden neue Sicherheitslücken entdeckt, die nie behoben werden, Prüfer beginnen, Fragen zu stellen, und das Ökosystem rund um 10.6 entwickelt sich still und leise weiter.

Dieser Beitrag befasst sich mit dem Zeitplan für 10.6, den konkreten Auswirkungen des End-of-Life auf Ihre Umgebung und den realistischen Optionen, die Ihnen zur Verfügung stehen. Wenn Sie nach einer schnellen Antwort à la „Einfach upgraden, das ist kein Problem“ suchen, sind Sie hier falsch. Das Upgrade einer Produktionsdatenbank ist selten so einfach, wie es aus der Ferne erscheint, und das Ziel dieses Beitrags ist es, Ihnen dabei zu helfen, den Weg zu wählen, der zu Ihrer Situation passt.

Abbildung 1. MariaDB-LTS-Versionen und die von der Community festgelegten End-of-Life-Termine. 10.6 ist die nächste Version, deren Support ausläuft.

MariaDB-Versionen und Lebenszyklen – ein kurzer Überblick

MariaDB veröffentlicht zwei Arten von Releases. „Rolling Releases“ erscheinen etwa vierteljährlich und werden nur bis zum nächsten Release unterstützt. „Long-Term Support“-Releases (LTS) erscheinen etwa einmal jährlich und werden über einen längeren Zeitraum hinweg gewartet, wobei Fehlerbehebungen und Sicherheitspatches bereitgestellt werden. In Produktionssystemen sollte ein LTS-Release eingesetzt werden.

MariaDB 10.6 ist eine LTS-Version. Sie wurde erstmals am 6. Juli 2021 veröffentlicht und hat einen fünfjährigen Supportzeitraum, sodass ihr Support am 6. Juli 2026 endet. Seitdem hat MariaDB den Community Server auf ein jährliches LTS-Modell mit einem dreijährigen Supportzeitraum umgestellt, beginnend mit Version 11.8 (Version 11.4 bleibt weiterhin eine LTS-Version mit fünfjährigem Support). Hier ist der Stand der aktuellen LTS-Versionen im Juni 2026:

Zwei Dinge fallen besonders auf. Erstens: 10.4 und 10.5 haben ihr Lebensende bereits überschritten, und 10.6 steht als Nächstes an, sodass der Großteil der 10.x-Reihe nicht mehr unterstützt wird – 10.11 LTS, das bis Februar 2028 unterstützt wird, bildet die einzige Ausnahme.  Zweitens sind die unterstützten LTS-Versionen 10.11 (bis Februar 2028), 11.4 (bis Mai 2029), 11.8 (bis Juni 2028) und 12.3 (die neueste LTS-Version, bis 2029). Für Teams, die von 10.6 umsteigen, ist 10.11 der geringste Kompatibilitätsaufwand, bietet aber die kürzeste Laufzeit, während 11.4 und 12.3 den längsten Support bieten und daher im Mittelpunkt der meisten Upgrade-Gespräche stehen.

Was passiert, wenn MariaDB 10.6 das Ende der Lebensdauer erreicht?

Das Ende des Lebenszyklus bedeutet, dass jegliche Wartungsarbeiten eingestellt werden. Für MariaDB 10.6 führt dies zu drei Problemen, die sich mit der Zeit verschärfen:

1. Die Bereitstellung von Sicherheitspatches wird eingestellt

Das ist der Punkt, der wirklich Schaden anrichtet. Nach dem 6. Juli 2026 werden Sicherheitslücken, die den MariaDB Community Server betreffen, nur noch in den unterstützten Community-Zweigen behoben, während der Community Server 10.6 diese Korrekturen nicht mehr erhält. Die Datenbank-Engine ist ein besonders attraktives Ziel – sie speichert die Daten und ist oft von Anwendungsservern aus erreichbar –, und schon eine einzige Schwachstelle kann alles dahinter offenlegen.

Das Ausnutzungsmuster bei Versionen, deren Lebensdauer abgelaufen ist, ist allgemein bekannt. Wenn ein Projekt einen Patch für eine unterstützte Version veröffentlicht, ist dieser öffentlich zugänglich, sodass Angreifer genau sehen können, welcher Code geändert wurde, und daraus den zugrunde liegenden Fehler ableiten können. Anschließend suchen sie in den EOL-Versionen, für die niemals Patches veröffentlicht werden, nach genau dieser Schwachstelle. Automatisierung und KI-gestützte Analysen können dieses Reverse Engineering beschleunigen, sodass sich die Zeitspanne zwischen der Veröffentlichung eines öffentlichen Patches und der Entwicklung eines funktionierenden Exploits schnell verkürzen kann. Eine EOL-Datenbank ist genau die Art von Ziel, die dieses Muster begünstigt. 

2. Compliance- und Prüfungsrisiken nehmen zu

Die meisten Sicherheitsrahmenwerke verlangen die zeitnahe Behebung bekannter Probleme. Die Anforderung 6 des PCI DSS erwartet von Organisationen, dass sie Schwachstellen identifizieren, nach ihrem Risikograd einstufen und beheben, wobei Patches für kritische und hochgradige Schwachstellen innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen (6.3.3 in Version 4.0.1). SOC-2-Prüfer können nicht unterstützte Komponenten kennzeichnen, wenn diese ungelöste Risiken im Bereich Schwachstellenmanagement oder Änderungsmanagement verursachen. In HIPAA-regulierten Umgebungen kann nicht unterstützte Software Zweifel daran aufkommen lassen, ob technische Sicherheitsvorkehrungen und Risikomanagementpraktiken weiterhin angemessen sind. FedRAMP und ähnliche Rahmenwerke erwarten eine kontinuierliche Patching-Praxis mit entsprechender Dokumentation.

Das Frustrierende daran ist, dass die Datenbank die einzige veraltete Komponente in einem ansonsten einwandfreien System sein kann und dennoch zu einem Beanstandungspunkt bei einem Audit führt. Bei der Prüfung von Cyberversicherungen wird möglicherweise auch nicht mehr unterstützte Software unter die Lupe genommen, insbesondere wenn ein Vorfall oder ein Verlängerungsprozess Lücken im Patch- und Schwachstellenmanagement aufdeckt.

3. Das Ökosystem driftet ab

Sobald eine Version das Ende ihrer Lebensdauer (EOL) erreicht, wird sie von der umgebenden Software nach und nach nicht mehr unterstützt. Mit der Zeit stellen Linux-Distributionen, Container-Images und Repositorys von Drittanbietern ihre Standard-MariaDB-Pakete zunehmend auf neuere, unterstützte Versionen um. Nach sechs Monaten zeigt sich dies in Form einer wachsenden Anzahl festgesteckter Versionen und Workarounds, und das Upgrade, das Sie aufgeschoben haben, ist still und leise schwieriger geworden, statt einfacher.

Abbildung 2. Die drei Risikobereiche, die sich ansammeln, sobald eine Datenbank das Ende ihrer Lebensdauer erreicht hat.

Welche Möglichkeiten haben Sie nach dem Ende des Supports für MariaDB 10.6?

Ihr optimaler Weg hängt davon ab, wie kritisch die Datenbank ist, wie viel betrieblichen Aufwand Sie in Kauf nehmen möchten und wie Ihr realistischer Zeitplan für das Upgrade aussieht. Es gibt vier Optionen, die in Betracht gezogen werden sollten.

Abbildung 3. Vier Möglichkeiten nach Ablauf der Lebensdauer von MariaDB 10.6 mit den jeweiligen Vor- und Nachteilen.

Option 1: Upgrade auf eine unterstützte LTS-Version (10.11, 11.4, 11.8 oder 12.3)

Dies ist die Standardlösung und die richtige Entscheidung, sofern man sie sauber umsetzen kann. Der Wechsel zu einer unterstützten LTS-Version stellt die offiziellen Sicherheitspatches wieder her und kann, je nach Zielversion, Verbesserungen in Bereichen wie dem Optimierer, der JSON-Verarbeitung, der Replikation und den Betriebswerkzeugen mit sich bringen. MariaDB gewährleistet in der Regel die Kompatibilität der Client-Server-Protokolle, doch das Anwendungsverhalten, die SQL-Semantik, die Replikation, das Binlog-Format, die Connector-Versionen und die Konfigurationseinstellungen müssen vor einem größeren Upgrade dennoch getestet werden.

Das Problem ist, dass ein großer Versionssprung bei einer Produktionsdatenbank eine Überprüfung des Schemas und der Konfiguration, die Validierung der Replikationstopologien, das Testen des Anwendungsverhaltens mit der neuen Version sowie die Planung eines Ausfall- oder Umstellungsfensters erfordert. MariaDB 11.0 hat ein neues Kostenmodell für den Optimierer eingeführt – und manche Abfragen können dadurch langsamer werden –, daher lohnt es sich, Ihre tatsächliche Arbeitslast auf einer Staging-Kopie auszuführen, um etwaige Änderungen am Ausführungsplan zu erkennen, bevor sie in die Produktion gelangen. Ein gängiger Ansatz mit geringerem Risiko besteht darin, die Zielversion unter realem Datenverkehr anhand einer Replik oder einer wiederhergestellten Staging-Kopie zu validieren und dann den Umstellungs- und Rollback-Pfad zu planen, bevor die Version in die Produktion übernommen wird. Die genaue Replikations- und Promotionsstrategie hängt von Ihrer Topologie und der Anzahl der überbrückten Hauptversionen ab; überprüfen Sie daher zunächst den unterstützten Upgrade-Pfad. 

Option 2: Umstieg auf MariaDB Enterprise Server

MariaDB plc vertreibt eine kommerzielle Enterprise-Server-Version von 10.6, die bis 23. August 2029, also etwa drei Jahre über den Stichtag der Community hinaus. Da die Version weiterhin zur 10.6-Serie gehört, handelt es sich eher um einen Distributionswechsel als um ein Upgrade auf eine neue Hauptversion, wobei Unternehmensfunktionen und Hersteller-Support hinzugefügt werden.

Die Nachteile sind ein kostspieliges kostenpflichtiges Abonnement, eine gewisse Anbieterabhängigkeit sowie der Wechsel von der Community-Distribution zu einer anderen Binärdistribution. Für Teams, die speziell den vom Anbieter unterstützten MariaDB Enterprise Server 10.6 mit Unterstützung für die STIG-Konformität benötigen, kann dies eine sinnvolle Lösung sein. Für Teams, deren Hauptziel darin besteht, ihre bestehende Open-Source-Bereitstellung auf dem neuesten Stand zu halten, kann dies jedoch mehr Aufwand bedeuten, als das Problem erfordert.

Option 3: Selbst verwalten oder einen Fork erstellen

Grundsätzlich können Sie den Open-Source-Code von 10.6 nutzen, CVEs selbst verfolgen und Korrekturen in Ihren eigenen Build zurückportieren. In der Praxis ist dies jedoch kaum auf Dauer durchzuhalten. Das Zurückportieren von Sicherheitskorrekturen erfordert Ingenieure, die in der Lage sind, einen umfangreichen C- und C++-Code korrekt zu lesen und zu patchen, die Korrekturen zu validieren und dies nach dem Zeitplan zu tun, der durch neue Sicherheitslücken vorgegeben wird – und nicht nach dem, den Sie bevorzugen würden. Die meisten Teams können dies personell nicht zuverlässig gewährleisten, und ein nur halbherzig durchgeführter Ansatz ist schlimmer als gar kein Plan, da er ein falsches Gefühl der Absicherung vermittelt.

Option 4: Erweiterte Sicherheit mit lebenslangem Support

Das ist der pragmatische Mittelweg, den Teams oft unterschätzen. Der TuxCare Endless Lifecycle Support für MariaDB sorgt dafür, dass Ihre aktuelle 10.6-Bereitstellung auch nach dem Ende des Community-Supportes gegen neue Sicherheitslücken gepatcht bleibt. TuxCare verfolgt CVEs in MariaDB, portiert die Korrekturen zurück in Ihre Open-Source-Version und stellt sie als Drop-in-Paketersatz über den von Ihnen bereits verwendeten Paketmanager bereit. Es sind keine Neuprogrammierungen von Anwendungen erforderlich, und das Ziel ist es, bestehende Replikations- und Backup-Workflows mit minimalen Betriebsunterbrechungen beizubehalten.

Der Sinn dieser Option besteht darin, die Dringlichkeit von Sicherheitsmaßnahmen von den technischen Kapazitäten zu entkoppeln. Patches werden weiterhin bereitgestellt, die Anwendung läuft weiter, und Ihr Team führt Upgrades nach einem Zeitplan durch, der sich an den tatsächlichen technischen Gegebenheiten orientiert und nicht an einem festen Kalendertermin. Dies ist sinnvoll, wenn Ihr Upgrade realistischerweise nicht vor dem 6. Juli 2026 abgeschlossen sein wird, wenn Sie Compliance-Verpflichtungen haben, die eine kontinuierliche, dokumentierte Patch-Installation erfordern, oder wenn die Bereitstellung stabil ist und ein überstürztes größeres Upgrade zum jetzigen Zeitpunkt einfach nicht gerechtfertigt ist.

Warum ein Upgrade nicht immer die naheliegendste Lösung ist

Auf dem Whiteboard sieht ein Upgrade ganz einfach aus. In der Praxis ist die Sache jedoch komplizierter, und zwar aus einigen Gründen, die man leicht unterschätzt.

Abhängigkeiten und Integrationen sind in der Regel die eigentlichen Hindernisse. Die MariaDB-Engine selbst verlangsamt Upgrades selten. Was sie verlangsamt, sind der Anwendungscode, die gespeicherten Prozeduren, die Replikationskonfiguration und die zugehörigen Tools, die alle vom Verhalten Ihrer aktuellen Version ausgehen. Die Bearbeitung dieser Punkte nimmt Zeit in Anspruch, die ein festgelegtes EOL-Datum nicht berücksichtigt.

Überstürzte Upgrades sind sehr kostspielig. Sie bringen Fehler mit sich, übersehen Randfälle und sparen beim Testen an der falschen Stelle. Die Kosten zeigen sich im nächsten Quartal in Form von Vorfällen und erhöhtem Bereitschaftsaufwand und übersteigen oft die Kosten eines langsameren, geplanten Upgrades, selbst wenn man den verlängerten Support mit einberechnet.

Bei manchen Systemen lohnt sich der Aufwand derzeit nicht. Eine Datenbank, die hinter einer Anwendung steht, deren Austausch geplant ist, oder eine, die eine feste Arbeitslast verarbeitet und für die keine neuen Funktionen geplant sind, rechtfertigt möglicherweise in diesem Jahr kein größeres Upgrade. Für diese Systeme ist das Patchen der aktuellen Version bis zur geplanten Umstellung eine vertretbare technische Entscheidung und kein Notbehelf.

Sichern Sie MariaDB 10.6 ohne Upgrade – mit TuxCare

Für MariaDB 10.6 gilt ein festes Enddatum: der 6. Juli 2026. Danach stellt das Projekt die Bereitstellung von Patches ein, und jede neue Sicherheitslücke wirkt sich auf jeden Host aus, auf dem noch 10.6 läuft. Ein Upgrade auf eine unterstützte LTS-Version – 10.11, 11.4, 11.8 oder 12.3 – ist die richtige Lösung, wenn Sie dies sauber und innerhalb eines angemessenen Zeitrahmens durchführen können. Wenn dies nicht möglich ist, weil Abhängigkeiten noch nicht bereit sind, die Frist zu knapp ist oder der Aufwand die Störung nicht rechtfertigt, sorgt der erweiterte Support für Ihre Sicherheit, ohne Sie zu einer ungünstigen Migration zu zwingen.

TuxCare Endless Lifecycle Support für MariaDB schließt diese Lücke mit fortlaufenden, SLA-gestützten Sicherheitspatches für EOL-MariaDB-Versionen, die über Ihren bestehenden Paketmanager ohne Codeänderungen bereitgestellt werden. Wenn Sie wissen möchten, wie sich dies in Ihre Umgebung einfügt, sprechen Sie mit einem TuxCare-Experten. Das Ziel ist es, Ihnen die Kontrolle über den Upgrade-Zeitplan zu geben, nicht ihn zu ersetzen.

Zusammenfassung

Artikel Name

MariaDB 10.6 – Ende des Supports

Beschreibung

MariaDB 10.6 erreicht am 6. Juli 2026 das Ende seines Lebenszyklus. Informieren Sie sich über die Risiken eines Betriebs ohne Patches und vier Möglichkeiten, die Sicherheit zu gewährleisten: TuxCare ELS.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers