Azure Database for PostgreSQL und MySQL: Preise

Azure Database for PostgreSQL und Azure Database for MySQL berechnen als Flexible Server Rechenleistung je vCore und Stunde in den Stufen Burstable, General Purpose und Memory Optimized, bereitgestellten Speicher je GiB und Monat, IOPS und Durchsatz über dem inklusiven Niveau, Sicherungsspeicher über 100 Prozent des bereitgestellten Speichers hinaus und bei Hochverfügbarkeit einen Standby mit derselben Rechenleistung und demselben Speicher; die Azure Database for PostgreSQL Kosten eines Servers und die seines MySQL-Gegenstücks folgen demselben Schnitt. Den größten Posten bilden die vCores, weil sie rund um die Uhr laufen und ein Standby sie verdoppelt; Speicher und Sicherungen laufen auch bei gestopptem Server weiter.

Preisdimensionen

Beide Dienste teilen das Modell, unterscheiden sich aber in Grenzen und Namen: MySQL nennt die oberste Stufe in der Dokumentation Memory Optimized und auf der Preisseite Business Critical, und seine Speicher- und IOPS-Optionen weichen ab. Die Tabelle nennt beide, wo sie auseinanderlaufen; was alle verwalteten Datenbanken gemeinsam haben, steht auf der Seite zu verwalteten Datenbanken.

Die Rechenleistung ist die Stufe mal Serie mal vCores: Burstable läuft auf B-Serien mit 1 bis 20 vCores und einem Guthabenmodell, das unter der Basislinie Guthaben sammelt und darüber verbraucht; sind sie aufgebraucht, bleibt nur die Basisleistung, weshalb Microsoft die Stufe nicht für Produktion empfiehlt und ihr weder Hochverfügbarkeit noch bei MySQL Lesereplikate gibt. General Purpose bietet 4 GiB je vCore auf D-Serien, Memory Optimized 6,75 bis 9,5 GiB (MySQL 8 GiB) auf E-Serien, jeweils in mehreren Hardware-Generationen mit eigenem Preis je vCore. vCores lassen sich jederzeit nach oben und unten ändern, Speicher nur nach oben.

Hochverfügbarkeit stellt einen Standby mit derselben Konfiguration bereit, zonenredundant in einer anderen Verfügbarkeitszone oder in derselben Zone; für MySQL sagt Microsoft ausdrücklich, dass Rechenleistung und Speicher für Primary und Standby bezahlt werden, und für PostgreSQL zeigt das Portal beim Einschalten die Kostensteigerung des Standby an. Der Standby ist nicht lesbar. Sicherungen werden trotz Standby nur einmal gehalten und einmal berechnet.

Speicher ist bereitgestellte Kapazität, nicht belegte: Was einmal vergrößert wurde, von Hand oder durch Autogrow, bleibt berechnet. Bei MySQL ist Autogrow standardmäßig an und wächst unter 100 GB um 5 GB, sobald weniger als 10 Prozent frei sind, darüber um 5 Prozent, sobald weniger als 10 GB frei sind; bei Servern mit Hochverfügbarkeit lässt es sich nicht abschalten. IOPS hängen an der Speichergröße: Premium SSD bringt je Größe feste IOPS mit (120 bei 32 GiB, 5.000 bei 1 TiB), mehr kosten je bereitgestellter IOPS und Monat; Premium SSD v2 enthält die ersten 3.000 IOPS (12.000 ab 512 GiB) und berechnet darüber je IOPS und je MB/s Durchsatz. MySQL bietet wahlweise vorab bereitgestellte zusätzliche IOPS oder Autoscale IOPS, die je verbrauchter Million I/O-Vorgänge abgerechnet werden.

Sicherungsspeicher ist bis zu 100 Prozent des bereitgestellten Speichers kostenlos: Ein Server mit 250 GiB hat 250 GiB Sicherungsspeicher frei, und bei 25 GiB täglicher Sicherungsmenge reichen die für zehn Tage. Darüber kostet jedes GB je Monat. Hohe Transaktionslast erzeugt unabhängig von der Datenbankgröße mehr WAL- oder Binlog-Dateien und damit mehr Sicherungsspeicher. Geo-redundante Sicherung kopiert alles in die Partnerregion, die Sicherungsgröße verdoppelt sich, und Microsoft rechnet sie als ((2 × lokale Größe) − bereitgestellter Speicher) × Preis.

Stoppen spart nur Rechenleistung: Ein gestoppter PostgreSQL-Server wird nach sieben Tagen automatisch gestartet, ein MySQL-Server nach 30 Tagen, und in der Zwischenzeit laufen bereitgestellter Speicher und Sicherungsspeicher weiter, bei MySQL auch bereitgestellte IOPS; der Sicherungsfreibetrag gilt bei MySQL nur für aktive Server. Reserved Capacity senkt den vCore-Preis um bis zu 65 Prozent für ein oder drei Jahre, gilt je Region und Leistungsstufe mit vCore-Flexibilität innerhalb der Stufe und deckt weder Speicher noch Sicherung noch Netzwerk; die Mechanik steht unter Azure-Reservierungen.

So erscheint es in den Abrechnungsdaten

Im Kostenexport tragen die Posten MeterCategory Azure Database for PostgreSQL oder Azure Database for MySQL; die Ressource ist der Server (Microsoft.DBforPostgreSQL/flexibleServers, Microsoft.DBforMySQL/flexibleServers). Der Standby einer Hochverfügbarkeits-Konfiguration hat keine eigene Ressource: Seine vCores und sein Speicher stehen auf den Metern des Primary, der dann die doppelte Menge zeigt. Ein Lesereplikat dagegen ist ein eigener Server mit eigener Ressourcen-ID. Die Meter der Retail-Prices-API sind dieselben wie im Export; serviceName, productName und meterName erscheinen dort als MeterCategory, ProductName und MeterName.

Drei Dinge landen anderswo: eine Langzeitaufbewahrung über Azure Backup erscheint als PostgreSQL Protected Instance unter MeterCategory Backup (Azure-Backup- und Site-Recovery-Preise), private Endpunkte berechnet Private Link und ausgehender Datentransfer steht auf den Bandbreiten-Metern (Azure-Bandbreiten- und Netzwerkpreise), und Diagnoseprotokolle in einem Log-Analytics-Arbeitsbereich zahlt Azure Monitor (Azure-Monitor- und Log-Analytics-Preise). Im FOCUS-Export tragen die Zeilen ServiceName Azure Database for PostgreSQL oder Azure Database for MySQL, ServiceCategory Databases und ChargeCategory Usage; eine Reservierung ist eine Zeile mit ChargeCategory Purchase, und die gedeckten vCore-Stunden tragen ihre CommitmentDiscountId. Den Export erklärt Azure-Kostenexporte, die Spalten FOCUS-Spalten und die Zuordnung der Anbieter.

Stellhebel

Konfiguration:

• Stufe und Größe nach Auslastung. vCores lassen sich in Sekunden ändern; eine Entwicklungsdatenbank gehört in Burstable, eine Produktionsdatenbank mit stabiler CPU-Last in die kleinste General-Purpose-Größe, die sie trägt. Das Vorgehen beschreibt Rightsizing.
• Server außerhalb der Arbeitszeit stoppen. Stoppen setzt die vCore-Stunden auf null, PostgreSQL für höchstens sieben Tage am Stück, MySQL für 30; Speicher und Sicherung laufen weiter. Zeitpläne dafür stehen unter Zeitplanung und Auto-Scaling.
• Speicher knapp bereitstellen, Autogrow einschalten. Bereitgestellter Speicher kostet, nicht belegter, und er schrumpft nie; Autogrow wächst in kleinen Schritten, wenn es nötig wird. Premium SSD v2 löst die festen Größenstufen auf und enthält 3.000 IOPS. Die Muster sammelt die Speicheroptimierung.
• Aufbewahrung und Redundanz der Sicherung prüfen. Jeder Tag über sieben hinaus und jede geo-redundante Kopie vergrößert den Sicherungsspeicher über den Freibetrag; die Metrik Backup Storage Used zeigt, wo er steht.

Kaufoption:

• Reserved Capacity für Produktionsserver. Bis zu 65 Prozent auf die vCores einer Stufe und Region, mit Größenflexibilität innerhalb der Stufe; Speicher und Sicherung bleiben Listenpreis. Wie viel davon ein Commitment decken sollte, behandelt die Commitment-Strategie.

Architektur:

• Hochverfügbarkeit nur, wo das SLA sie verlangt. Der Standby verdoppelt vCores und Speicher und ist nicht lesbar; Test- und Staging-Server brauchen ihn selten. Die Abwägung gehört in die Architekturentscheidungen.
• Lesereplikate zählen. Jedes Replikat ist ein voller Server; ein Replikat für Berichte, das nur am Monatsende liest, kostet den ganzen Monat. Weitere Muster beschreibt die Datenbankoptimierung.
• Hauptversion aktuell halten. Nach Ende des Community-Supports berechnet Microsoft Extended Support je vCore und Stunde zusätzlich zur Rechenleistung.

Wo es schiefgeht

• Der gestoppte Server kostet weiter. Symptom: Ein seit Tagen gestoppter Server erzeugt Speicher- und Sicherungsposten. Ursache: Nur die Rechenleistung entfällt; bereitgestellter Speicher, Sicherungsspeicher und bei MySQL bereitgestellte IOPS laufen weiter, und nach sieben (PostgreSQL) oder 30 Tagen (MySQL) startet der Server von selbst.
• Hochverfügbarkeit verdoppelt. Symptom: Die vCore- und Speichermenge eines Servers ist doppelt so hoch wie seine Konfiguration erwarten lässt. Ursache: Der Standby steht auf den Metern des Primary.
• Der Speicher wächst und schrumpft nicht. Symptom: Der Speicherposten steigt in Stufen und bleibt oben, obwohl Daten gelöscht wurden. Ursache: Autogrow oder eine Vergrößerung von Hand; Speicher lässt sich nur nach oben skalieren.
• Sicherungsspeicher über dem Freibetrag. Symptom: Ein Posten Backup Storage auf einem Server mit kleiner Datenbank. Ursache: Lange Aufbewahrung, geo-redundante Kopie oder hohe Transaktionslast, die mehr WAL- oder Binlog-Dateien schreibt als die Datenbank groß ist.
• Extended Support taucht auf. Symptom: Ein neuer Posten je vCore-Stunde neben der Rechenleistung. Ursache: Die Hauptversion hat das Ende des Community-Supports erreicht.
• Burstable in Produktion. Symptom: Der Server wird langsam oder unerreichbar, und ein Upgrade folgt im Monat darauf. Ursache: Die CPU-Guthaben sind aufgebraucht, und die Stufe läuft auf der Basisleistung weiter; Microsoft empfiehlt sie nicht für Produktion.

Beispiel

Germany West Central, Listenpreise in EUR aus der Azure Retail Prices API, gelesen am 2026-10-21. PostgreSQL Flexible Server: General Purpose Ddsv5 0,0933 EUR je vCore und Stunde (4 vCores 0,3731 EUR), Memory Optimized Edsv5 0,1329 EUR je vCore und Stunde, Burstable B1ms 0,0175 EUR und B2s 0,07 EUR je Stunde; Speicher 0,1206 EUR je GiB und Monat, zusätzliche IOPS 0,0524 EUR je IOPS und Monat, Premium SSD v2 IOPS 0,0229 EUR; Sicherungsspeicher LRS 0,0906 EUR je GB und Monat; Extended Support 0,0801 EUR je vCore und Stunde. MySQL Flexible Server: General Purpose Ddsv5 0,0893 EUR und Memory Optimized Edsv5 0,1257 EUR je vCore und Stunde, B1ms 0,0175 EUR je Stunde, Speicher 0,1206 EUR je GB und Monat, zusätzliche IOPS 0,0524 EUR je IOPS und Monat, Autoscale IOPS 0,2288 EUR je Million I/O-Vorgänge, Sicherungsspeicher 0,0906 EUR je GB und Monat. Ein PostgreSQL-Server mit D4ds_v5 und 256 GiB Speicher kostet über 730 Stunden 0,3731 × 730 = 272,36 EUR plus 256 × 0,1206 = 30,87 EUR, zusammen 303,24 EUR; mit zonenredundanter Hochverfügbarkeit verdoppeln sich Rechenleistung und Speicher auf 606,47 EUR, während die Sicherung einmal gehalten bleibt. Der Standby ist der teuerste einzelne Schalter des Dienstes.

Quellen

Gelesen am 2026-10-21. Microsoft, PostgreSQL: Azure Database for PostgreSQL Flexible Server Preise, Compute options, Storage options, Backup and restore, High availability, Configure high availability, Stop compute of a server, Prepay for compute resources with reserved capacity. MySQL: Azure Database for MySQL Flexible Server Preise, Service tiers, Storage IOPS, Backup and restore, High availability, Stop and start a server. Abrechnungsdaten: Understand cost details fields, FOCUS cost and usage details file schema, Azure Retail Prices REST API. Preise: Retail-Prices-Abfrage für Azure Database for PostgreSQL in Germany West Central in EUR, Retail-Prices-Abfrage für Azure Database for MySQL in Germany West Central in EUR.