Shopware, PHP, MySQL: Wann läuft was aus?

Warum End of Life kein Randthema ist

End of Life, kurz EOL, ist der Zeitpunkt, ab dem eine Software keine Updates mehr bekommt, auch keine Sicherheitsupdates. Für einen Onlineshop ist das kein akademisches Datum: Ab dem EOL bleibt jede neu entdeckte Lücke dauerhaft offen. Wer Kartenzahlungen abwickelt, ist über den Sicherheitsstandard PCI-DSS ohnehin auf unterstützte Software festgelegt, und die DSGVO verlangt in Artikel 32 Schutzmaßnahmen nach dem Stand der Technik. Veraltete Software ist damit nicht nur ein technisches, sondern auch ein rechtliches Risiko.

Der Haken: Ein Shop besteht aus mehreren Schichten, und jede hat ihr eigenes EOL. Über allem liegt Shopware selbst, darunter PHP als Programmiersprache und darunter die Datenbank, meist MySQL oder MariaDB. Dieser Beitrag stellt die Termine zusammen und zeigt, worauf es dabei wirklich ankommt. Stand: August 2026, die Tabellen altern.

Das schwächste Glied entscheidet

Die wichtigste Einsicht vorweg: Eine Shopware-Version kann nur so lange sicher betrieben werden, wie es eine unterstützte PHP- und Datenbank-Version gibt, auf der sie läuft. Die aktuellste Shopware-Version nützt nichts, wenn das darunterliegende PHP keine Patches mehr bekommt; umgekehrt hilft ein frisches PHP nicht, wenn die Shopware-Version selbst am Ende ist. Die effektive Lebensdauer eines Shops ist deshalb der früheste EOL-Termin in dieser Kette, nicht der späteste.

Das folgende Diagramm zeigt alle drei Ebenen auf einer Zeitachse. Grün steht für aktiven Support, orange für die Phase mit reinen Sicherheitsfixes, die rote Markierung für das End of Life. Alles, was links der gestrichelten Heute-Linie endet, ist bereits abgelaufen.

Ablesen lässt sich das Muster sofort: Shopware 6.4, PHP 8.1 und MySQL 5.7 wie auch MySQL 8.0 enden vor der Heute-Linie, sind also nicht mehr abgesichert. Die genauen Termine je Ebene stehen in den Tabellen darunter.

Shopware 6.4 bis 6.7

Eine Besonderheit vorweg: Shopware nennt keine festen Kalender-EOL wie PHP. Die offizielle Doku sagt ausdrücklich, dass die Support-Übergänge am Erscheinen der nächsten Major-Version hängen, nicht an festen Terminen. Nur die jeweils neueste Minor-Version bekommt aktive Bugfixes; ältere erhalten nur noch Sicherheitsfixes, teils ausschließlich über das kostenlose Security-Plugin. Die konkreten Daten unten stammen daher aus endoflife.date und sind als Orientierung zu verstehen, nicht als verbindliche Shopware-Zusage.

PHP: harte Termine

Bei PHP ist die Lage eindeutig, denn php.net veröffentlicht feste Termine. Jede Version bekommt zwei Jahre aktiven Support und danach zwei Jahre nur noch kritische Sicherheitsfixes.

MySQL und MariaDB

Auch die Datenbanken haben feste Termine (MySQL, MariaDB). Entscheidend ist hier nicht die neueste, sondern die Mindestversion, die eine Shopware-Version voraussetzt.

Ein Zusatz zur Herkunft: Diese Termine gelten für die Originalversionen, also Oracle MySQL Community und MariaDB. Wer MySQL nicht direkt von Oracle bezieht, ist oft nicht schlagartig ungeschützt. Percona Server für MySQL 8.0 lief erst im Juni 2026 aus und bietet darüber hinaus mehrjährigen Post-EOL-Support mit Sicherheitsfixes, und Managed-Hoster sowie Distributions-Pakete backporten Security-Patches meist über das Oracle-Datum hinaus. Für ein selbst betriebenes Oracle-MySQL 8.0 gilt der April-2026-Termin dagegen unmittelbar.

Die Kette zusammengesetzt

Jetzt wird die Abhängigkeit sichtbar. Die folgende Tabelle zeigt je Shopware-Version die neueste unterstützte PHP- und die geforderte Mindest-Datenbank, jeweils mit ihrem EOL. Die PHP-Angaben stammen aus der composer.json der jeweiligen Version, die Datenbank-Angaben aus den Upgrade-Hinweisen und dem Hosting-Guide von Shopware.

So gelesen wird der Punkt klar: Shopware 6.4 ist doppelt am Ende, denn selbst die neueste PHP-Version, die 6.4 unterstützt, ist seit Ende 2025 EOL, und die passende Datenbank ebenso. Wer noch 6.4 fährt, betreibt seinen Shop auf einer Plattform, für die es nirgends mehr Sicherheitsfixes gibt.

Bei 6.5 und 6.6 bindet zuerst der Shopware-Zyklus. Aber Achtung: Beide setzen als Datenbank-Minimum MySQL 8.0 voraus, und das ist seit April 2026 EOL. Wer auf genau dieser Mindestversion sitzt, hat also schon heute eine abgekündigte Datenbank unter einem noch unterstützten Shop. Der saubere Ausweg ist MariaDB 10.11, das 6.6 ausdrücklich unterstützt und das noch bis 2028 Support hat. Erst 6.7 nennt als empfohlene Datenbanken MariaDB 11.4 und MySQL 8.4, beide mit langem Support.

Die zwei akuten Fälle

Zwei Termine verdienen jetzt Aufmerksamkeit. Erstens: MySQL 8.0 ist seit April 2026 EOL. Viele Shopware-Shops laufen noch darauf, unabhängig von ihrer Shopware-Version. Als Update-Ziel ist MariaDB 11.4 LTS die naheliegende Wahl: Sie ist die in Shopware-Setups verbreitetste Datenbank, und viele Managed-Hoster liefern sie als Standard. MySQL 8.4 wird zwar ebenfalls unterstützt, prüft Fremdschlüssel aber deutlich strenger, woran manche Erweiterungen noch nicht angepasst sind, sodass der Wechsel auf MariaDB in der Praxis der reibungsärmere Weg ist. Den Umzug selbst erleichtert die Shopware-CLI: Ihr Dump-Befehl erzeugt einen sauberen Datenbank-Export, der sich in die neue Engine einspielen lässt. Zweitens: PHP 8.2 erreicht Ende 2026 sein EOL. Shopware 6.7 verlangt mindestens PHP 8.2, aber wer auf 8.2 steht, sollte den Schritt auf 8.3 oder 8.4 noch 2026 einplanen.

Was jetzt zu tun ist

Der erste Schritt ist eine ehrliche Bestandsaufnahme: Welche Shopware-, PHP- und Datenbank-Version läuft im eigenen Shop? Diese drei Werte gegen die Tabellen oben halten, den frühesten EOL-Termin heraussuchen, und das ist die Deadline, an der ein Update spätestens fällig ist. Ein Versionsupdate innerhalb von Shopware 6 ist dabei keine Migration im Sinne eines Systemwechsels, sondern ein planbares Update, das sich mit Test auf einer Kopie und Backup gut beherrschen lässt.

Wer diesen Weg nicht allein gehen möchte, findet über die Wartung Unterstützung: Ein regelmäßiger Update-Check hält Shopware, PHP und Datenbank im Blick und plant fällige Sprünge ein, bevor ein EOL-Termin zum Problem wird, statt hinterher auf einen Vorfall zu reagieren.