MariaDB im Hosting: Wer hält Ihre Version aktuell?

Der MariaDB-Beitrag vom 31. Oktober erinnert an ein früheres Ereignis: Community 10.6 erreichte am 6. Juli 2026 ihr Wartungsende. Der vorherige Release-Bericht nennt 10.6.28 vom 13. August als letzte Ausgabe. Das Wartungsende trat also nicht erst in dieser Woche ein. (MariaDB Foundation, MariaDB Foundation)

Vier Angaben statt eines Versionsetiketts

«MariaDB ist enthalten» ist für eine Wartungsentscheidung zu ungenau. Eine brauchbare Bestandsaufnahme verbindet die tatsächlich laufende Version mit Paketquelle, Betreiber und zugesagter Pflege. Fragen Sie zusätzlich, für welche Instanz und welchen Zeitpunkt die Antwort gilt. Ein Produktblatt kann mehrere Tarife oder inzwischen ersetzte Umgebungen zusammenfassen.

Lizenz und Wartungszusage beantworten verschiedene Fragen

Die offizielle Policy nennt GPLv2 für MariaDB Server. Sie unterscheidet Community-, Enterprise- und Extended-Pflege sowie Fristen für Binärpakete und Quellcode. Eine Lizenzangabe allein belegt deshalb keinen aktiven Wartungsvertrag für eine bestimmte Installation. (MariaDB Foundation)

Wenn Ihr Anbieter ergänzende Pflege zusagt, verlangen Sie eine konkrete Zuordnung: Welche Instanz, welche Fehlerkorrekturen, welcher Bezugsweg und wer installiert sie? Stellen Sie diese Fragen ohne vorwegzunehmen, dass eine alte Versionsnummer automatisch denselben Zustand bei jedem Betreiber bedeutet. Ebenso wenig reicht das Wort «Enterprise», wenn der tatsächlich gebuchte Umfang unklar bleibt.

Die Anwendung muss ebenfalls mitspielen

WordPress empfiehlt derzeit MariaDB 10.11 oder neuer beziehungsweise MySQL 8.0 oder neuer. Das sind Anforderungen und Empfehlungen einer Anwendung, keine Aussage über die Installation Ihres Hostings. (WordPress.org)

Für eine eigene Versionsentscheidung brauchen Sie beide Seiten: einen tragfähigen Wartungsweg und eine mit Ihren Erweiterungen, Abfragen und Betriebswerkzeugen geprüfte Anwendung. Eine höhere Versionsnummer ersetzt diese Prüfung nicht. Sammeln Sie deshalb zuerst die Abhängigkeiten, die einen Wechsel beeinflussen: Plugins, Connectoren, benutzerdefinierte SQL-Abfragen und Überwachung.

Eine Antwort des Hosters in einen nächsten Schritt übersetzen

Hypothetischer Fall: Ein Betreiber bestätigt eine 10.6-Installation, aber nicht, woher die Pakete stammen oder ob weitere Korrekturen abgedeckt sind. Dann fehlt zunächst Wartungsevidenz. Eine sofortige Zusage «wir wechseln direkt auf Version X» würde eine zweite unbekannte Entscheidung daraufsetzen.

• Bitten Sie um die fehlende schriftliche Zuordnung von Paketquelle, Abdeckung und Verantwortlichem.
• Legen Sie fest, wer Anwendung und Datenbank gemeinsam prüfen kann; bei Managed Hosting braucht es die Beteiligung des Betreibers.
• Planen Sie eine getrennte Testumgebung und ein belastbares Wiederherstellungsverfahren, bevor eine Produktionsänderung terminiert wird.
• Definieren Sie fachliche Abnahmepfade, etwa Anmeldung, Suche und eine erlaubte Testtransaktion. Ein startender Datenbankprozess ist dafür nur ein Teilnachweis.

Diese Schritte sind ein vorgeschlagenes Vorgehen, kein hier ausgeführter Upgrade-Test. Sie sollen Unsicherheiten in überprüfbare Aufgaben verwandeln. Konkrete Installationsbefehle wären ohne Kenntnis von Paketquelle, Konfiguration und Verantwortung kein verlässlicher nächster Schritt.

Was Sie budgetieren müssen

Zur Entscheidung gehören Aufwand für Inventar, Kompatibilitätsprüfung, Tests, Betreiberkoordination und eine gegebenenfalls notwendige Unterbrechung. Ein frei lizenzierter Server macht diese Arbeit nicht kostenlos. Preise und Laufzeiten eines kommerziellen Pflegeangebots müssen aus dem tatsächlichen Vertrag stammen; hier werden keine Tarife oder Ausfallzeiten versprochen.

Am Ende sollte für die vorhandene Installation eine eindeutige Aussage stehen: Wer liefert Korrekturen, wer spielt sie ein und wie wird die Anwendung danach überprüft? Erst mit diesen Antworten lässt sich die nächste Versionsentscheidung sachlich begründen.