Managed oder self-hosted PostgreSQL – diese Frage begegnet mir in meinen Azure-Kursen regelmäßig, und die Antwort ist selten eindeutig. Microsoft hat die zentralen Entscheidungsparameter nun in einem strukturierten Blogbeitrag aufbereitet: Kosten, Kontrolle, Sicherheit, Resilienz, Skalierbarkeit und operativer Aufwand stehen dabei im Mittelpunkt. Wer die Abwägung kennt, trifft bessere Architekturentscheidungen.
Bei Managed PostgreSQL übernimmt der Cloud-Anbieter – in diesem Fall Microsoft mit dem Azure Database for PostgreSQL Flexible Server – Betrieb, Patching, Backups, Hochverfügbarkeit und Monitoring. Self-hosted PostgreSQL hingegen bedeutet: PostgreSQL läuft auf einer Azure-VM oder in einem Container, die gesamte Betriebsverantwortung liegt beim eigenen Team.
Was steckt hinter dem Vergleich?
Microsoft stellt die Unterschiede entlang von sechs Dimensionen gegenüber. Kompakt zusammengefasst:
| Kriterium | Managed (Flexible Server) | Self-hosted (VM/Container) |
|---|---|---|
| Kosten | Kalkulierbare Servicegebühr, kein Ops-Aufwand | VM-Kosten niedriger, aber Personalaufwand höher |
| Kontrolle | Eingeschränkt (kein Superuser, keine Extensions nach Belieben) | Volle Kontrolle über Konfiguration und Extensions |
| Sicherheit | Automatische Patches, integriertes Microsoft Defender-Angebot | Eigenverantwortung für Härtung und Updates |
| Resilienz | Integrierte Hochverfügbarkeit und Point-in-Time-Restore | Selbst zu implementieren (Azure Backup, Replikation) |
| Skalierbarkeit | Vertikales Scaling und Read Replicas per Klick | Manuell, flexibler aber aufwändiger |
| Operativer Aufwand | Gering – ideal für kleine Teams | Hoch – setzt PostgreSQL-Expertise voraus |
Was bedeutet das für Azure-Admins und Architekten?
Ich hatte mich in diesem Zusammenhang selbst schon mehrfach mit Kunden auseinandergesetzt, die auf Self-hosted PostgreSQL bestanden hatten – oft mit dem Argument der Kostenersparnis. In der Praxis stellte sich dann heraus, dass allein die Personalkosten für Betrieb, Patching und Backup-Validierung die vermeintliche Ersparnis zunichtemachten.
Merksatz: Self-hosted PostgreSQL rechnet sich primär dann, wenn Sie spezifische Extensions benötigen, die der Managed Service nicht unterstützt, oder wenn regulatorische Anforderungen eine besondere Konfigurationstiefe verlangen.
Für die meisten KMU und mittelgroße Workloads ist Azure Database for PostgreSQL Flexible Server die pragmatischere Wahl: weniger Betriebsaufwand, SLA-gesicherte Verfügbarkeit und integrierte Sicherheitsfunktionen ohne zusätzliche Infrastruktur. Wer tiefer in die Datenbankarchitektur auf Azure einsteigen möchte, findet in meinen Azure-Kursen dedizierte Module zu PaaS-Datenbankdiensten und deren Entscheidungskriterien.
Praxistipp: Prüfen Sie vor der Entscheidung konkret, welche PostgreSQL-Extensions Ihre Anwendung benötigt. Die offizielle Liste unterstützter Extensions für den Flexible Server ist ein schneller Filter: Steht Ihre Extension nicht drauf, ist Self-hosted möglicherweise alternativlos – ansonsten spricht fast immer mehr für Managed.
Alle Details zur Analyse und weiteren Trade-offs finden Sie in der Originalankündigung bei Azure Blog.