Azure Database for PostgreSQL (Flexible Server) ist für viele Teams der „schnelle Start". Das Problem kommt später: Sobald Last, Daten und Verfügbarkeit steigen, wird aus Komfort oft eine Kosten- und Abhängigkeitsstruktur, die sich nur schwer wieder zurückdrehen lässt.

Die größte Exit-Hürde ist selten Technik – sondern Unsicherheit: „Verlieren wir HA?", „Wie machen wir Backups und PITR?", „Wie ersetzen wir Monitoring ohne Azure-Telemetrie-Abrechnung?" Die Antwort ist: Du verlierst nichts. Du holst dir Kontrolle zurück – und baust ein Setup, das genauso professionell läuft, aber nicht an ein proprietäres Ökosystem gebunden ist.

Das Beste: Du musst das nicht selbst aufbauen und betreiben. Bei OutaCloud richten wir deinen PostgreSQL-HA-Cluster auf Proxmox ein und managen ihn – für einen Bruchteil dessen, was du Azure für Flexible Server zahlen würdest. Gleiche Zuverlässigkeit, kein Lock-in, planbare Kosten.

Inhaltsverzeichnis

1) Was Azure dir beim Managed-Postgres wirklich berechnet
2) Retail vs. Wholesale: Azure-VM (vergleichbar) vs. Hetzner AX42
3) Service Replacement: Azure Database for PostgreSQL ersetzen – ohne Feature-Verlust
4) High Availability auf Proxmox: zwei Patterns, beide „enterprise-ready"
- Option A: Patroni-Cluster (klassisch, flexibel, infra-nah)
- Option B: CloudNativePG (Kubernetes-native, sehr sauber automatisierbar)
5) Backups: PITR für Daten + PBS für Infra (das ist die Kombi, die funktioniert)
6) Monitoring ohne Azure-Tax: Grafana + Prometheus + Loki – vollständig, nicht „abgespeckt"
7) Migration von Azure Postgres: „ohne Datenverlust" ist ein Prozess, kein Spruch
Fazit
Bereit, dein Azure Postgres zu migrieren?

1) Was Azure dir beim Managed-Postgres wirklich berechnet

Azure Flexible Server ist nicht „eine Zahl". Abgerechnet wird getrennt nach Compute, Storage und Backup-Storage – und bei HA wird es schnell doppelt relevant: Zone-redundante HA bedeutet Primary + Secondary Replica, und du zahlst für Compute und Storage beider Seiten. Zusätzlich gelten Standard-Netzwerkgebühren für Egress.

Das ist kein „Azure-Bashing", sondern pure Mechanik: In der Praxis werden Managed-DB-Kosten oft unterschätzt, weil sie nicht nur aus „vCores" bestehen, sondern aus mehreren Positionen, die mit Datenvolumen und Verfügbarkeit multiplizieren.

2) Retail vs. Wholesale: Azure-VM (vergleichbar) vs. Hetzner AX42

Wenn wir „vergleichbare Hardware-Ressourcen" gegenüberstellen, ist die Azure-VM-Klasse Standard D16as v5 eine passende Referenz: 16 vCPUs, 64 GB RAM. On-Demand liegt sie in gängigen Preislisten bei rund $0.688 pro Stunde – das sind grob ~$502/Monat nur Compute (ohne Disks, ohne Backup-/Traffic-Themen, ohne Datenbank-PaaS-Aufschläge).

Auf der anderen Seite steht als sehr typischer Proxmox-Baustein der Hetzner AX42: AMD Ryzen 7 PRO 8700GE, 64 GB DDR5 ECC, 2×512 GB NVMe (Gen4, RAID1), 1 Gbit/s, Unlimited Traffic, ab 46 €/Monat (+ einmaliges Setup).

Das ist der Kern eurer „Compute-Tax"-Story: Hyperscaler-Compute ist Retail-Pricing plus Ökosystem-Overhead. Dedizierte Infrastruktur ist planbarer – und vor allem: Sie bleibt unter Kundenshoheit.

3) Service Replacement: Azure Database for PostgreSQL ersetzen – ohne Feature-Verlust

Wenn Teams an Azure Postgres hängen, dann wegen drei Dingen: Verfügbarkeit, Backups (inkl. PITR) und Betriebs-Komfort. Genau diese drei Dinge bilden wir auf Proxmox sauber ab – nur eben transparent, offen und ohne Vendor-Lock-in.

Der wichtigste Perspektivwechsel: PITR ist kein Azure-Feature. PITR ist ein PostgreSQL-Mechanismus aus Base-Backups plus kontinuierlicher WAL-Archivierung. Wenn du die WAL-Kette sauber führst, kannst du auf einen Zeitpunkt zurückrollen – genau das, was Teams an Managed-Diensten so schätzen.

4) High Availability auf Proxmox: zwei Patterns, beide „enterprise-ready"

Je nach Stack und Team-DNA bauen wir HA-PostgreSQL typischerweise in einem von zwei Mustern:

Option A: Patroni-Cluster (klassisch, flexibel, infra-nah)

Patroni ist stark, wenn du PostgreSQL klassisch in VMs betreibst und ein robustes Failover-Pattern brauchst. Patroni ist explizit für HA-Postgres gedacht und unterstützt u. a. etcd/Consul/ZooKeeper/Kubernetes als Distributed Config Store zur Cluster-Koordination.

In der Praxis bedeutet das: Du fährst 3 DB-Nodes (1 Primary, 2 Replicas), ein kleines Quorum/Config-Backend, und setzt davor sauberes Routing (z.B. VIP/Proxy). Failover wird nicht „manuell nachts um 3", sondern automatisiert und kontrollierbar.

Option B: CloudNativePG (Kubernetes-native, sehr sauber automatisierbar)

CloudNativePG ist ideal, wenn ihr Kubernetes-first seid oder bewusst dahin wollt. CloudNativePG unterstützt auch synchrone Replikation-Modelle (z. B. quorum- oder priority-basiert) und kann Writes stoppen, wenn die geforderte Zahl synchroner Standbys nicht verfügbar ist – also ein sehr klares Konsistenz-/Durability-Verhalten.

Welche Option „besser" ist, hängt nicht am Tool-Logo, sondern an euren Anforderungen: RPO/RTO-Ziele, Write-Profil, Operability, und wie ihr Deployments/Changes im Alltag fahren wollt.

5) Backups: PITR für Daten + PBS für Infra (das ist die Kombi, die funktioniert)

Wir trennen bewusst zwei Ebenen:

Ebene 1: Datenbank-PITR (PostgreSQL-native) Auf Datenbank-Ebene wird PITR über Base-Backups und WAL-Archivierung umgesetzt – das ist die saubere Lösung, wenn du „zurück auf 12:37 Uhr vor dem Fehler" willst.

Ebene 2: Infrastruktur-Backups (Proxmox Backup Server) Auf Infrastruktur-Ebene setzen wir Proxmox Backup Server (PBS) als Sicherheitsnetz ein: deduplizierte Datastores auf Chunk-Basis reduzieren Speicherbedarf und machen Restores schnell und zuverlässig, auch über viele Snapshots hinweg. Zusätzlich kann PBS Backup-Daten clientseitig verschlüsseln und nutzt TLS für die Kommunikation – wichtig, wenn Backups auf getrennte Standorte/Targets gehen.

Ergebnis: Du bekommst operationalen Komfort zurück – aber als Engineering-System, nicht als Blackbox.

6) Monitoring ohne Azure-Tax: Grafana + Prometheus + Loki – vollständig, nicht „abgespeckt"

Auf Proxmox ersetzen wir Azure-Monitoring nicht „irgendwie", sondern vollständig: Wir fahren einen Observability-Stack mit Prometheus (Metriken), Grafana (Dashboards/Alerting) und Loki (Logs). Damit bilden wir sowohl Infrastruktur-Signale (CPU/IO/Netz) als auch Postgres-Signale (Replication Lag, Locks, Connections, Query-Last, Autovacuum-Health) ab – ohne metered Ingest-/Query-Überraschungen und ohne proprietäre Limits.

Kurz: Kein Kompromiss gegenüber Azure-Komfort – nur mit mehr Transparenz und ohne Lock-in.

7) Migration von Azure Postgres: „ohne Datenverlust" ist ein Prozess, kein Spruch

Der zuverlässige Weg ist immer gleich: Ziel parallel aufbauen, Daten synchronisieren, Validierung fahren, dann kontrolliert cutten. Wie „nahezu downtime-frei" es wird, hängt vor allem an Datenbankgröße, Write-Profil und eurer Toleranz für ein Maintenance-Fenster. Wichtig ist: Wir definieren das vorab vertraglich/operativ sauber – nicht erst im Go-Live.

Fazit

Azure Database for PostgreSQL ist bequem – aber ersetzbar, ohne Reliability zu verlieren. Mit Proxmox als Plattform, einem klaren HA-Pattern (Patroni oder CloudNativePG), PITR-fähigem Backup-Design und Observability via Grafana/Prometheus/Loki bekommst du genau den Betriebs-Komfort, den du brauchst – nur unter deiner Hoheit und mit planbarer Kostenstruktur.

Wenn du Azure verlassen willst, aber nicht auf Reliability verzichten möchtest, ist Service Replacement der schnellste Weg aus dem Lock-in.

Auch auf AWS? Lies unseren AWS RDS zu PostgreSQL Guide.

Bereit, dein Azure Postgres zu migrieren?

Wir kümmern uns um alles – von der Einrichtung bis zum laufenden Betrieb. Unser Managed PostgreSQL bildet exakt ab, was du von Azure Flexible Server kennst: automatisches Failover, Point-in-Time Recovery, Monitoring, Backups, Updates. Der Unterschied? Du zahlst einen Bruchteil der Kosten und besitzt deine Infrastruktur.

Wir migrieren deine Azure-PostgreSQL-Workloads ohne Datenverlust und liefern dir einen belastbaren Cutover-Plan.

Starte hier:

Exit Azure – Übersicht unserer Azure-Migrationsservices
Azure zu Hetzner – Detaillierter Guide zur Migration zu Hetzner
Berechne deine Ersparnis – Sieh, wie viel du sparen könntest

Oder kontaktiere uns direkt für eine kostenlose Infrastruktur-Analyse.

Bye Bye Azure Postgres: Managed PostgreSQL auf Proxmox – ohne Kompromisse