Ein Stichtag, zwei völlig verschiedene Konsequenzen

Am 6. Juli 2026 hat MariaDB Community Server 10.6 sein Lebensende erreicht. Die MariaDB Foundation formuliert das unmissverständlich: Für diesen Zweig gibt es keine Fehlerkorrekturen mehr, keine Sicherheitskorrekturen und keine weiteren korrigierenden Releases. Wer das liest, zieht schnell den naheliegenden Schluss — „also läuft meine Datenbank ab jetzt ungepatcht".

Dieser Schluss ist für einen Teil der Betreiber zutreffend und für einen anderen Teil schlicht falsch. Denn was Ihre Datenbank an Sicherheitsupdates bekommt, entscheidet nicht allein der Hersteller. Es entscheidet ebenso, aus welcher Quelle die Software auf Ihrem Server installiert wurde und ob dafür ein Supportvertrag besteht. Beides sind Angaben, die die wenigsten Betreiber über ihren eigenen Server sicher machen können — und ohne die sich die Lage nicht beurteilen lässt.

Darum geht es in diesem Beitrag: nicht um Alarm, sondern um die Frage, welcher von drei Fällen bei Ihnen zutrifft — und wie Sie das mit einer einzigen E-Mail klären.

Auf einen Blick

  • MariaDB Community Server 10.6 hat am 6. Juli 2026 sein Lebensende erreicht — die MariaDB Foundation liefert für diesen Zweig keine Fehler- und keine Sicherheitskorrekturen mehr.
  • Ein Support-Ende beim Hersteller bedeutet nicht automatisch, dass Ihr Server keine Sicherheitsupdates mehr bekommt — das hängt an der Distribution und an einem etwaigen Supportvertrag.
  • Drei Fälle sind zu unterscheiden: direkt vom Hersteller installiert, aus der Distribution ohne Supportvertrag, aus der Distribution mit Supportvertrag.
  • Drei Fragen klären Ihren Fall: Welche Version läuft? Aus welcher Quelle stammt sie? Wer liefert dafür die Sicherheitsupdates?
  • Einen einzelnen empfohlenen Nachfolger nennt MariaDB ausdrücklich nicht — mehrere Versionen kommen infrage, und die neuere ist nicht automatisch die länger gepflegte.

Was am 6. Juli tatsächlich endete

Zunächst das Naheliegende: Am 6. Juli ist nichts ausgefallen. Eine MariaDB 10.6 läuft danach technisch unverändert weiter, Ihre Anwendung startet wie gewohnt, Abfragen laufen durch. Was endet, ist der Nachschub an Korrekturen aus dem Entwicklungszweig — und zwar für alle drei genannten Kategorien: Fehler, Sicherheitslücken und korrigierende Releases.

Ebenso wichtig ist, was am 6. Juli nicht passiert ist: Ihr Server wurde an diesem Tag nicht unsicherer. Am 7. Juli war er exakt so sicher wie am 5. Juli — dieselbe Software, dieselben bekannten und behobenen Lücken. Das Risiko eines Support-Endes ist kumulativ: Es entsteht nicht am Stichtag, sondern wächst mit jeder Schwachstelle, die künftig gefunden und in diesem Zweig nicht mehr geschlossen wird. Genau deshalb ist ein Support-Ende ein Planungsthema und kein Notfall — vorausgesetzt, man plant tatsächlich.

Und es ist deshalb auch kein Grund, die Sache jetzt hektisch zu behandeln. Es ist ein Grund, sie einmal sauber zu klären. Denn ob dieser versiegende Nachschub Ihren Server überhaupt trifft, ist die eigentlich offene Frage.

Warum „Support-Ende" nicht automatisch „ungeschützt" heißt

Der Hersteller ist bei Open-Source-Datenbanken nicht zwingend derjenige, der Ihre Updates liefert. Sehr oft installiert man eine Datenbank nämlich gar nicht beim Hersteller, sondern nimmt sie aus der Paketverwaltung des Betriebssystems — und dann ist der Anbieter dieses Betriebssystems derjenige, der Sicherheitskorrekturen zusammenstellt und ausliefert. Ob und wie weit er das zusagt, ist wiederum eine Frage der Vertragslage. Daraus ergeben sich drei Fälle, die man auseinanderhalten muss.

Fall 1: Direkt vom Hersteller installiert

Wurde MariaDB 10.6 direkt aus den Quellen des Herstellers installiert, gilt die Aussage der MariaDB Foundation unmittelbar: Für diesen Zweig kommt nichts mehr nach. Hier ist der Schluss „ab jetzt keine Fixes mehr" korrekt — und hier besteht Handlungsbedarf, der sich nicht wegdiskutieren lässt. Das ist der Fall, für den der aufgeregte Ton in vielen Meldungen tatsächlich passt.

Fall 2: Aus Ubuntu 22.04, ohne Ubuntu Pro

Hier wird es differenzierter. Ubuntu 22.04 LTS führt das Paket „mariadb-10.6" in der Version 1:10.6.23-0ubuntu0.22.04.1, zuletzt hochgeladen im November 2025. Entscheidend ist dabei ein Detail, das nach reiner Formsache klingt und keines ist: Das Paket liegt in der Komponente „universe" — nicht in „main".

Diese Unterscheidung hat handfeste Folgen. Die Standard-Sicherheitspflege einer Ubuntu-LTS-Version deckt „main" ab. Für „universe" galt historisch die Formulierung, dass Canonical keine Zusicherung zur Sicherheitspflege gibt, Pflege aber nach bestem Bemühen erfolgte. Das ist ein wichtiger Unterschied, der oft verkürzt wiedergegeben wird: Der Punkt ist „keine Zusicherung" — nicht „gar nichts". Wer hier pauschal von einem ungepatchten Server spricht, geht über die Faktenlage hinaus; wer sich umgekehrt auf die Pflege verlässt, verlässt sich auf etwas, das niemand versprochen hat.

Für Sie heißt das: Dieser Fall ist der einzige, der sich nicht vom Schreibtisch aus entscheiden lässt. Hier muss man nachfragen, nicht raten. Zur Einordnung des Zeitrahmens: Ubuntu 22.04 LTS erhält Standard-Sicherheitspflege bis Mai 2027.

Fall 3: Aus Ubuntu 22.04, mit Ubuntu Pro

Besteht ein Ubuntu-Pro-Abonnement, sieht die Lage anders aus als in Fall 2. Der Stream „esm-apps" deckt sämtliche Pakete aus „universe" ab, und zwar zehn Jahre ab dem Erscheinen der LTS-Version. Canonical beschreibt das ausdrücklich so, dass alle Pakete aus „universe" damit dieselbe Zusicherung zur Sicherheitspflege erhalten wie Pakete aus „main".

Dieser Leser ist also nicht ungeschützt — und das ist der Punkt, an dem die naheliegende Schlagzeile zum Support-Ende in die Irre führt. Was allerdings ebenso stimmt: Es bleibt eine alternde Version, deren Entwicklung beim Hersteller abgeschlossen ist. Aus dem Notfall wird damit ein Planungsvorgang mit Zeitpuffer — aus der Entscheidung wird er nicht.

Die drei Fragen an Ihren Dienstleister

Das Erfreuliche an dieser Gemengelage: Sie müssen sie nicht selbst auflösen. Sie müssen nur drei Fragen stellen — an Ihren Hoster, Ihre Webagentur oder Ihren IT-Dienstleister, je nachdem, wer den Server betreut. Diese drei Fragen passen in eine einzige E-Mail:

  • Welche Datenbankversion läuft bei uns im Einsatz? Die genaue Versionsnummer, nicht nur der Produktname — der Unterschied zwischen 10.6 und 10.11 ist an dieser Stelle der ganze Unterschied.
  • Aus welcher Quelle stammt diese Version? Direkt vom Hersteller installiert oder aus den Paketquellen der Distribution? Diese Frage entscheidet, welcher der drei Fälle bei uns zutrifft.
  • Wer liefert dafür Sicherheitsupdates — und mit welcher Zusage? Gibt es einen Supportvertrag, der die Datenbank abdeckt, oder verlassen wir uns auf Pflege ohne Zusicherung?

Erfahrungsgemäß ist die dritte Frage die unangenehmste, und genau deshalb ist sie die wichtigste. Eine belastbare Antwort darauf lautet nicht „das läuft schon", sondern nennt einen Namen und eine Zusage. Bleibt eine der drei Fragen unbeantwortet oder kommt sie ausweichend zurück, ist das bereits ein Ergebnis: Dann weiß derzeit niemand, wer Ihre Datenbank absichert — und das gilt es zu klären, bevor über Versionen gesprochen wird.

Was ein Wechsel bedeutet

Fällt die Entscheidung für einen Wechsel, folgt eine Frage, auf die es keine bequeme Antwort gibt: wohin. MariaDB nennt bewusst keinen einzelnen empfohlenen Nachfolger, sondern hält für viele Anwender mehrere Versionen für passend — 10.11, 11.4, 11.8 oder 12.3.

Dabei lohnt ein Blick auf die Lebenszyklen, denn sie verlaufen nicht so, wie man es intuitiv erwarten würde:

VersionVerfügbar seitLebensende
10.1116.02.202316.02.2028
11.429.05.202429.05.2029
11.804.06.202504.06.2028
12.329.05.202629.05.2029

Die Tabelle enthält eine Pointe, die in der Praxis Geld kostet: Die neuere Version ist nicht automatisch die länger gepflegte. Version 11.8 ist rund ein Jahr jünger als 11.4 — und läuft trotzdem fast ein Jahr früher aus. Wer nach dem Prinzip „möglichst aktuell" wählt, kann sich damit ausgerechnet den kürzeren Zeithorizont einhandeln und in wenigen Jahren erneut vor derselben Aufgabe stehen. Die sinnvolle Frage lautet deshalb nicht „was ist am neuesten", sondern „welche Version trägt uns am längsten, ohne dass unsere Anwendung dabei aus dem Tritt kommt".

Und das ist der Teil, der Vorlauf braucht. Eine Datenbank ist kein Programm, das für sich allein steht — an ihr hängt Ihre Fachanwendung, Ihr Shop, Ihr Warenwirtschaftssystem. Ein Versionswechsel muss deshalb zur Anwendung passen, will getestet sein und braucht ein Zeitfenster, in dem ein Rückweg offensteht, falls etwas klemmt. Wie aufwendig das im Einzelfall wird, hängt von der Anwendung ab und lässt sich nicht pauschal beziffern. Trivial ist es selten.

Einordnung

Das Lebensende von MariaDB 10.6 ist keine Nachricht, die Ihren Betrieb heute betrifft — und für einen Teil der Leser ist es überhaupt keine schlechte Nachricht. Wer Ubuntu Pro einsetzt, hat Zusagen im Rücken und Zeit. Wer direkt beim Hersteller installiert hat, sollte den Wechsel jetzt terminieren. Und wer es nicht weiß, hat in Wahrheit kein Datenbankproblem, sondern eine offene Frage — die sich in einer E-Mail stellen lässt.

Genau darin liegt der Wert dieses Stichtags. Nicht in der Dringlichkeit, sondern darin, dass er einen Anlass gibt, ein System einmal bewusst anzusehen, das sonst niemand ansieht, weil es einfach läuft. Die ehrliche Botschaft zu MariaDB 10.6 lautet deshalb nicht „Ihr Server ist offen", sondern: Klären Sie, welcher Fall bei Ihnen zutrifft. Diese Antwort sollten Sie über Ihre zentrale Datenbank haben — unabhängig davon, welches Datum im Kalender steht.

Wenn Sie nicht sicher sind, welche Datenbankversion hinter Ihrer Anwendung arbeitet und wer sie mit Sicherheitsupdates versorgt, übernehmen wir die Bestandsaufnahme. Wir klären mit Ihnen und den beteiligten Dienstleistern, was tatsächlich im Einsatz ist, welcher der drei Fälle zutrifft — und planen, falls nötig, den Übergang so, dass Ihr Tagesgeschäft davon nichts merkt.