PostgreSQL 14 auf Azure: Ab 1. Februar 2027 kostet jeder vCore extra

Was Extended Support kostet

Laut Preisseite kostet Extended Support 0,07 US-Dollar je vCore und Stunde in den ersten zwei Jahren und 0,14 US-Dollar ab dem dritten Jahr. Bei 730 Stunden sind das 51,10 beziehungsweise 102,20 US-Dollar je vCore und Monat.

• Server mit 4 vCores (D4ds_v5, Listenpreis 259,88 US-Dollar im Monat): plus 204,40 US-Dollar, also rund 79 Prozent mehr.
• Ab Februar 2029 für denselben Server: plus 408,80 US-Dollar im Monat.
• Server mit 16 vCores: plus 817,60 US-Dollar im Monat in den ersten zwei Jahren.

Verrechnet wird nur, solange ein Server im Zustand „Succeeded“ läuft. Gestoppte, gelöschte oder fehlgeschlagene Server kosten keinen Extended Support. Wer mitten im Monat aktualisiert, zahlt nur die Zeit bis zum Upgrade. Ob bei Hochverfügbarkeit auch der Standby-Server zählt, nennt die Preisseite nicht. Das sollte vor der Budgetplanung geklärt sein.

Was Extended Support leistet und was nicht

Enthalten sind Sicherheitsupdates, Korrekturen kritischer Fehler und technischer Support im Rahmen des bestehenden Supportplans, bis längstens 11. November 2029. Nicht enthalten sind neue Funktionen, Leistungsverbesserungen, allgemeine Fehlerkorrekturen, Hilfe bei der Leistungsoptimierung und Minor-Version-Upgrades. Microsoft beschreibt Extended Support selbst als vorübergehende Brücke bis zum Upgrade.

Warum PostgreSQL 15 als Ziel kaum Zeit verschafft

Azure unterstützt die neueren Versionen jeweils bis zum Ende der Community-Pflege. Wer jetzt nur auf Version 15 geht, steht im November 2027 wieder vor demselben Problem.

Ein In-Place-Upgrade darf Versionen überspringen. Version 17 ist bis November 2029 unterstützt, Version 18 bis November 2030. Für die meisten Umgebungen ist ein direkter Sprung auf 17 oder 18 sinnvoller als zwei Upgrades in einem Jahr. Eine Ausnahme ist TimescaleDB: Von 14 aus erlaubt Azure ein In-Place-Upgrade nur auf 15 oder 16.

Betroffene Server finden

Diese Abfrage im Azure Resource Graph listet alle Flexible Server mit Versionen ohne Standardunterstützung, einschließlich 11 bis 13, die bereits seit August 2026 im Extended Support sind.

resources
| where type =~ 'microsoft.dbforpostgresql/flexibleservers'
| extend version = tostring(properties.version)
| where version in ('11', '12', '13', '14')
| project name, resourceGroup, location, version, sku = tostring(sku.name),
    ha = tostring(properties.highAvailability.mode), state = tostring(properties.state)
| order by version asc

Die vCores ergeben sich aus dem SKU-Namen, D4ds_v5 hat zum Beispiel 4 vCores. Das Azure-Portal kennzeichnet außerdem Server, die sich dem Ende der Unterstützung nähern oder bereits im Extended Support sind.

Das Upgrade vorbereiten

• Upgrade-Validierung im Portal oder mit der Azure CLI ausführen. Sie findet blockierende Erweiterungen, Replikations-Slots, Event Trigger und offene Konfigurationsänderungen, ohne Ausfallzeit.
• Erweiterungen prüfen. session_variable, anon und age blockieren jedes Upgrade, pg_repack, hypopg und pg_partman müssen vorher entfernt und danach neu angelegt werden.
• Lesereplikate vor dem Upgrade löschen und danach neu erstellen. Bei Hochverfügbarkeit schaltet Azure HA ab und nach dem Upgrade wieder ein, dafür muss Kapazität für einen neuen Standby vorhanden sein.
• 10 bis 20 Prozent freien Speicher sicherstellen und Netzwerkregeln für die Ports 5432 und 6432 sowie den Zugriff auf Azure Storage prüfen.
• In einer Testumgebung aus einer Point-in-Time-Wiederherstellung üben. Ein Rückweg nach dem Upgrade existiert nur über eine Wiederherstellung auf einen neuen Server.
• Nach dem Upgrade ANALYZE in jeder Datenbank ausführen, damit die Statistiken stimmen.

Verhindern regionale Kapazitätsengpässe das Upgrade, kann ein Server laut Microsoft vorübergehend von der Verrechnung ausgenommen werden. Das läuft über den Support.

Server für Server entscheiden

Die Kosten- und Migrationsanalyse erfasst alle betroffenen Server über Ihre Subscriptions, rechnet den Extended Support bis 2029 durch und legt je Server Zielversion und Reihenfolge fest. Das Upgrade selbst führt Ihr Team oder Ihr Dienstleister durch.