Wer bezahlt den Versionswechsel? PostgreSQL 14, Python 3.10 und der AWS-Aufpreis

Eine Anwendung, mehrere Ablaufdaten

Angenommen, Ihr Betrieb arbeitet mit einem Kundenportal, das ein Dienstleister vor einigen Jahren für Sie gebaut hat. Es läuft, niemand fasst es an. Unter der Oberfläche stecken aber Bausteine mit festem Ablaufdatum: eine Programmiersprache in einer bestimmten Version und eine Datenbank in einer bestimmten Version. Für zwei solche Bausteine liegen die Termine im Herbst 2026.

Am 1. Oktober 2026 ist Python 3.10.22 erschienen, die letzte Version der Reihe 3.10. Die Release-Seite des Python-Projekts sagt es ohne Umschweife: „Python 3.10 has reached end of life.“ Sicherheitsupdates gibt es für diese Reihe seitdem nicht mehr. Die Datenbank PostgreSQL 14 bekommt nach dem 12. November 2026 keine Korrekturen mehr. Und wer die Datenbank bei Amazon Web Services (AWS) betreiben lässt, hat es dort mit eigenen Terminen zu tun, die vom PostgreSQL-Projekt abweichen.

Wie ein Supportende grundsätzlich wirkt, haben wir am Beispiel von MariaDB 10.6 beschrieben; für .NET-Anwendungen gibt es einen eigenen Beitrag. Hier geht es um die Frage danach: Wer kümmert sich um den Wechsel, und wer bezahlt ihn? Darauf hat die Technik keine Antwort. Sie steht, wenn überhaupt, in Ihrer Vereinbarung mit dem Dienstleister.

Die Termine auf einen Blick

Zwei Begriffe vorab. Die Hauptversion ist die große Nummer, etwa 14 oder 15. Unterversionen wie 14.18 sind Korrekturstände innerhalb dieser Hauptversion. Laut AWS bringt ein Wechsel der Unterversion nur Änderungen, die mit bestehenden Anwendungen verträglich bleiben. Ein Wechsel der Hauptversion kann dagegen Änderungen bringen, die mit der Anwendung nicht kompatibel sind.

Python 3.10: seit 1. Oktober 2026 ohne Sicherheitsupdates

Bei Python ist kein weiterer Termin abzuwarten: Die Reihe 3.10 ist am 1. Oktober 2026 mit Version 3.10.22 ausgelaufen. Laut Release-Seite bekommt sie keine weiteren Sicherheitsupdates. Neu entdeckte Sicherheitslücken in Python 3.10 schließt das Python-Projekt also nicht mehr, und es empfiehlt, auf eine unterstützte Python-Version umzusteigen. Welche Version für Ihre Anwendung infrage kommt, lässt sich nur am Code beurteilen.

PostgreSQL 14: Was der 12. November 2026 bedeutet

Das PostgreSQL-Projekt pflegt jede Hauptversion fünf Jahre lang ab ihrer ersten Veröffentlichung. Danach erscheint eine letzte Unterversion, und die Version gilt als nicht mehr unterstützt. PostgreSQL 14 erschien am 30. September 2021. Als Termin der letzten Version nennt das Projekt auf seiner Seite zur Versionspflege den 12. November 2026. In der Ankündigung heißt es, PostgreSQL 14 erhalte nach diesem Tag keine Korrekturen mehr. Wer die Version im Produktivbetrieb einsetzt, dem rät das Projekt, den Umstieg auf eine neuere, unterstützte Version zu planen.

Gemeint ist das Ende der Pflege durch das Projekt. Dieser Termin zählt für Datenbanken auf eigenen Servern. Für verwaltete Datenbanken bei AWS gelten andere Daten.

Am Beispiel Amazon RDS: Aufpreis oder erzwungenes Upgrade

Läuft die Datenbank als verwalteter Dienst in der Cloud, betreibt der Anbieter die Datenbanksoftware für Sie. Wie sich das auf die Termine auswirkt, zeigt das Beispiel Amazon RDS, der Datenbankdienst von AWS. Andere Anbieter haben wir für diesen Beitrag nicht geprüft.

Bei RDS bleibt PostgreSQL 14 auch nach dem 12. November 2026 im Standard-Support von AWS, laut Release-Kalender bis zum 28. Februar 2027. Was danach passiert, entscheidet eine einzige Einstellung der Datenbank: der sogenannte Extended Support, also die verlängerte Pflege gegen Gebühr. AWS selbst schreibt dazu: „You can continue running a major version past its RDS end of standard support date for a fee.“

Fall 1: Extended Support ist eingeschaltet

Dann läuft die Datenbank weiter auf PostgreSQL 14. AWS liefert in dieser Zeit nach eigener Beschreibung Sicherheitsupdates für kritische und hoch eingestufte Schwachstellen sowie Korrekturen für kritische Fehler. Ab dem 1. März 2027 berechnet AWS dafür einen Aufpreis, ab dem 1. März 2029 gilt eine eigene Preisstufe für das dritte Jahr. Laut AWS fällt der Aufpreis auch für die Bereitschaftsinstanzen (Standby) an, die in sogenannten Multi-AZ-Bereitstellungen neben der eigentlichen Datenbank laufen. Wird Ihre Datenbank mit einer solchen Bereitschaftsinstanz betrieben, kostet also auch diese.

Die Kosten enden erst, wenn die Datenbank auf eine Version im Standard-Support gehoben oder gelöscht wird. Unbegrenzt geht das nicht: Extended Support gibt es höchstens drei Jahre über das Ende des Standard-Supports hinaus, für PostgreSQL 14 also bis zum 28. Februar 2030. Wer bis dahin nicht gewechselt hat, bekommt das Upgrade laut AWS automatisch.

Fall 2: Extended Support ist ausgeschaltet

Dann hebt AWS die Datenbank am oder kurz nach dem 28. Februar 2027 auf eine unterstützte Version. Die Dokumentation spricht an einer Stelle allgemein von „a supported engine version“. An anderer Stelle, für das Abschalten nach dem Stichtag, ist von der nächsten unterstützten Hauptversion die Rede. Eine bestimmte Versionsnummer nennt keine der beiden Stellen.

Das klingt bequem. Es hat aber zwei Haken. Erstens brauchen Upgrades der Datenbanksoftware laut AWS eine Ausfallzeit. Zweitens kann ein Wechsel der Hauptversion Änderungen bringen, die mit der bestehenden Anwendung nicht kompatibel sind. Ob Ihr Kundenportal danach noch fehlerfrei läuft, weiß vorher niemand, solange es niemand auf der neuen Version getestet hat.

Welcher Fall gilt bei Ihnen?

Das hängt an der Einstellung, die für Ihre Datenbank hinterlegt ist. Ihr Ausgangswert entstand beim Anlegen der Datenbank, und dabei kommt es auf den Weg an:

• Angelegt über die AWS-Konsole, die Bedienoberfläche von AWS: Extended Support ist dort nicht vorausgewählt. Beim Anlegen wird er nur aktiv, wenn ihn jemand ausdrücklich auswählt.
• Angelegt über die Kommandozeile (CLI), die Programmierschnittstelle (API) oder Automatisierung wie CloudFormation: Fehlt eine ausdrückliche Angabe, schaltet AWS Extended Support ein.

Die Einstellung lässt sich laut AWS später jederzeit über CLI oder API ändern, und zwar sofort und ohne Ausfallzeit. Welcher Fall gilt, klärt deshalb nicht die Erinnerung an das Anlegen, sondern ein Blick in die Konfiguration. Genau danach sollten Sie fragen.

Schon am 31. Oktober 2026: einzelne Unterversionen

Bei RDS können einzelne Unterversionen früher auslaufen als ihre Hauptversion. Für die Unterversionen 14.18 und 14.19, ebenso für 15.13, 15.14, 16.9, 16.10, 17.5 und 17.6 endet der Standard-Support bei AWS am 31. Oktober 2026. Das betrifft also nicht nur PostgreSQL 14, sondern auch einzelne Stände von 15, 16 und 17.

Erreicht eine Unterversion ihr Support-Ende, spielt AWS laut Dokumentation eine neuere Unterversion ein, auch wenn das automatische Unterversions-Upgrade nicht eingeschaltet ist. Das ist ein Wechsel innerhalb der Hauptversion, den AWS als verträglich mit bestehenden Anwendungen beschreibt. Eine Ausfallzeit bringt aber auch dieses Upgrade mit sich.

Was Sie Ihren Dienstleister fragen

Bevor Sie fragen, lohnt ein Blick in die eigenen Unterlagen: Wartungsvertrag, Leistungsbeschreibung, das letzte Angebot. Findet sich dort etwas zu Updates, zu Versionswechseln oder zu Kosten des Cloud-Anbieters, nehmen Sie die Stelle in Ihre Nachricht auf. Die folgenden Fragen passen in eine einzige E-Mail:

1. Welche Versionen laufen unter unserer Anwendung? Programmiersprache und Datenbank, jeweils mit Versionsnummer, Pflege-Ende und Betriebsort, also eigener Server oder Cloud-Dienst.
2. Läuft unsere Datenbank bei einem Cloud-Anbieter, und ist dort Extended Support eingeschaltet? Bei AWS entscheidet diese Einstellung zwischen Aufpreis und Upgrade.
3. Ist unsere Datenbank vom Termin am 31. Oktober 2026 für einzelne Unterversionen betroffen? Falls ja: Mit welcher Ausfallzeit rechnen Sie, und wann?
4. Wurde die Anwendung auf der Zielversion getestet? Gemeint sind eine unterstützte Python-Version und eine neuere PostgreSQL-Hauptversion. Falls nicht: Bis wann ist ein Test möglich?
5. Wie ist der Versionswechsel in unserem bestehenden Wartungsvertrag geregelt? Ist er enthalten, wird er gesondert abgerechnet, oder steht dazu nichts im Vertrag?
6. Wer trägt Aufpreise des Cloud-Anbieters, falls die Datenbank im Extended Support weiterläuft? Und wer entscheidet, ob es dazu kommt?

Bei den Fragen fünf und sechs geht es um Geld. Wir beantworten sie hier bewusst nicht. Was Ihr Vertrag regelt, lässt sich nur am Vertrag selbst beurteilen. Bleibt die Antwort Ihres Dienstleisters unklar, ist das Gespräch mit ihm der erste Schritt. Geht es um die Auslegung einzelner Klauseln, ist eine Rechtsberatung die richtige Adresse.

Was offen ist

Einiges kann dieser Beitrag nicht klären:

• Preise: Wie hoch der Aufpreis für Extended Support bei AWS ausfällt, steht auf den Preisseiten von AWS. Die haben wir nicht ausgewertet.
• Andere Cloud-Anbieter: Wir haben nur AWS geprüft. Wer seine Datenbank anderswo betreiben lässt, fragt dort nach den eigenen Terminen und Voreinstellungen.
• Zeitpunkt und Ziel des Unterversions-Upgrades: Wann genau AWS die betroffenen Unterversionen ersetzt und welche Unterversion dann eingespielt wird, konnten wir nicht belegen.
• Zielversion beim Hauptversions-Upgrade: AWS nennt keine feste Versionsnummer, siehe oben.
• Wer den Wechsel bezahlt: Das hängt an Ihrer Vereinbarung mit dem Dienstleister und lässt sich nicht allgemein beantworten.

Stand der Angaben ist der 1. Oktober 2026. An diesem Tag haben wir die Termine bei Python, beim PostgreSQL-Projekt und bei AWS nachgelesen.

Python 3.10 bekommt seit dem 1. Oktober 2026 keine Sicherheitsupdates mehr, hier steht der Umstieg also an. Bei AWS kommen zuerst die Unterversionen am 31. Oktober 2026, die Termine für PostgreSQL 14 folgen im Februar und März 2027. Wer aber nicht weiß, welche Versionen unter seiner Anwendung laufen und was im Vertrag zum Wechsel steht, sollte das klären, bevor ein Upgrade die Frage für ihn entscheidet.

Wenn Sie die Fragen nicht allein durchgehen möchten: Bei Individualsoftware übernehmen wir Beratung und Projektsteuerung. Wir klären mit Ihnen und Ihrem Dienstleister, welche Versionen unter Ihrer Anwendung laufen und was bis wann zu entscheiden ist.