RDS ist bequem – aber es ist auch der größte Klebstoff im AWS-Lock-in. Nicht weil PostgreSQL „nicht anders geht", sondern weil viele Teams Angst haben, danach auf zentrale Dinge zu verzichten: Failover, Backups, PITR, Monitoring, Wartung.

Die Wahrheit: Du kannst RDS sauber ersetzen – mit einem PostgreSQL-Setup auf Proxmox, das technisch erwachsen ist, wirtschaftlich planbar bleibt und trotzdem Cloud-Komfort liefert. Und genau da kommt Service Replacement ins Spiel.

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

Inhaltsverzeichnis

1) Was du bei RDS wirklich kaufst (und warum es teuer wird)
2) Kostenvergleich: RDS db.m5.4xlarge vs. Hetzner AX-Line (Der faire RAM-Vergleich)
3) Zwei bewährte Wege zu PostgreSQL-HA auf Proxmox
- Option A: Patroni-Cluster (klassisch, flexibel, infra-nah)
- Option B: CloudNativePG (Kubernetes-native, sehr sauber automatisierbar)
4) Backups & Recovery: So bekommst du RDS-PITR ohne RDS
- Unser praxistaugliches Modell: Zwei Ebenen statt Marketing
5) Monitoring ohne CloudWatch-Tax: Grafana + Prometheus + Loki (wirklich komplett)
6) Migration von RDS nach Proxmox: Wie du ohne Datenverlust rauskommst
7) Fazit: RDS ist ersetzbar – wenn man's richtig baut
Bereit, deine RDS zu migrieren?

1) Was du bei RDS wirklich kaufst (und warum es teuer wird)

Bei RDS zahlst du nicht nur „eine Datenbank". Die monatlichen Kosten setzen sich u.a. aus DB-Instance-Hours, Storage, I/O, Backup-Storage und Data Transfer zusammen. Genau diese „kleinen" Posten sorgen später für die unplanbaren Rechnungen – vor allem sobald Traffic und Datenvolumen wachsen.

Der Hebel beim Exit ist deshalb nicht nur „Compute günstiger", sondern: Kostenstruktur vereinfachen, „Metered Billing" rausnehmen, Egress-/Request-Tax entschärfen und gleichzeitig Features wie HA + Recovery nicht verlieren.

2) Kostenvergleich: RDS db.m5.4xlarge vs. Hetzner AX-Line (Der faire RAM-Vergleich)

Um Äpfel mit Äpfeln zu vergleichen, schauen wir uns Instanzen mit 64 GB RAM an.

Bei AWS ist das die RDS db.m5.4xlarge (16 vCPU / 64 GB RAM). In Frankfurt (eu-central-1) liegt der On-Demand-Preis bei ca. €1.063/Monat (Single-AZ). Wohlgemerkt: Nur für die Instanz. Ohne Storage, ohne Traffic, ohne Multi-AZ.

Auf der anderen Seite unser Zielsystem: Hetzner AX42 (8 Kerne / 64 GB DDR5 ECC RAM / 2x NVMe). Preis: ab 46 €/Monat.

Die Rechnung ist schockierend:

AWS: ~€1.063/Monat
Hetzner: ~€46/Monat
Differenz: Über €1.000 Ersparnis – jeden Monat, pro Datenbank-Server.

Selbst wenn wir für absolute Hochverfügbarkeit (HA) drei Hetzner-Server (Primary + 2 Standbys) hinstellen, landen wir bei Hardwarekosten von ~€140/Monat. Das ist immer noch 85% günstiger als eine einzelne AWS-Instanz.

3) Zwei bewährte Wege zu PostgreSQL-HA auf Proxmox

Es gibt zwei Setups, die wir in der Praxis je nach Team-DNA und Betriebsmodell bevorzugen. Beide funktionieren auf Proxmox zuverlässig – die Entscheidung ist nicht „richtig/falsch", sondern „passt zu eurem Stack".

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

Patroni ist ein etablierter Ansatz für HA-PostgreSQL mit automatischem Failover und Leader-Election über einen Distributed Config Store (z.B. etcd/Consul/ZooKeeper). Das ist besonders stark, wenn du PostgreSQL lieber „klassisch" in VMs oder systemnah betreibst und Kubernetes nicht dein operatives Zentrum ist.

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)

Wenn dein Betrieb ohnehin Kubernetes-zentriert ist (oder ihr bewusst dahin wollt), ist CloudNativePG eine extrem starke Lösung: Kubernetes-Operator für PostgreSQL-Cluster, HA-Management, Lifecycle-Automation, Backup/DR-Mechaniken. Streaming Replication ist Standard, synchronous Replication ist steuerbar bis hin zu „zero data loss replicas" – wenn du das so designst.

Auf Proxmox läuft das typischerweise als: K8s-Cluster auf Proxmox-VMs + CloudNativePG für Postgres. Du bekommst damit eine sehr deklarative, wiederholbare Betriebslogik.

4) Backups & Recovery: So bekommst du RDS-PITR ohne RDS

Die häufigste Angst beim RDS-Exit ist „Point-in-Time Recovery". Und hier ist der wichtige, ehrliche Punkt:

PITR ist ein PostgreSQL-Feature – nicht ein AWS-Feature. PostgreSQL-PITR basiert auf Base Backups + kontinuierlich archivierten WAL-Segmenten, sodass du bis zu einem Zeitpunkt/LSN zurückspulen kannst (z.B. „vor dem DROP TABLE").

Unser praxistaugliches Modell: Zwei Ebenen statt Marketing

Damit Recovery nicht nur „theoretisch möglich", sondern operativ stressfrei ist, trennen wir zwei Ebenen:

Ebene 1: Datenbank-PITR (PostgreSQL-native) Du nutzt ein Backup-Tooling wie pgBackRest/WAL-Archiving und stellst sicher, dass Base Backups + WAL-Archive lückenlos sind. Das liefert dir echtes PITR-Verhalten.

Ebene 2: Infrastruktur-Backups (Proxmox Backup Server) PBS ist dann dein Sicherheitsnetz für die gesamte VM/Container-Umgebung: inkrementell, dedupliziert, schnell wiederherstellbar – ideal für „wir müssen den Node exakt so wie gestern 02:00 zurückholen" oder Disaster-Recovery-Szenarien.

Das Ergebnis ist in der Praxis besser als „nur RDS": PITR für Daten plus schnelle Infra-Restores, ohne dass du bei jedem Restore in proprietäre AWS-Mechaniken gedrückt wirst.

5) Monitoring ohne CloudWatch-Tax: Grafana + Prometheus + Loki (wirklich komplett)

RDS-Teams unterschätzen oft, wie viel Observability sie in AWS bezahlen: Metrik-Ingest, Logs, Alarme, Dashboards, „mal eben mehr Retention".

Unser Standard-Ansatz auf Proxmox ist ein voller Observability-Stack: Prometheus für Metriken, Grafana für Dashboards/Alerting, Loki für Logs. Für PostgreSQL heißt das konkret: Query-/Connection-Last, Replication Lag, Locks, Autovacuum-Health, Disk-/IO-Pressure, Error Patterns – und Alarme, die nicht erst feuern, wenn die App schon brennt.

Das ist nicht „günstiger CloudWatch", sondern: bessere Sichtbarkeit, ohne Metered Billing.

6) Migration von RDS nach Proxmox: Wie du ohne Datenverlust rauskommst

„Ohne Datenverlust" ist kein Claim, das ist ein Prozess.

Der Kern ist immer: Du baust das Ziel sauber parallel auf, replizierst/synchronisierst, testest und cuttest dann kontrolliert.

In der Umsetzung hängt die Methode von Größe und Downtime-Toleranz ab: Bei kleineren Datenbanken reicht oft Dump/Restore plus kurzer Maintenance-Cut. Bei Produktionssystemen mit strikteren Anforderungen arbeitest du mit Replikation/Sync-Strategien, um die Downtime auf ein Minimum zu drücken.

Was dabei entscheidend ist: Extensions/Parameter-Tuning, Connection Pooling, Backup/Restore-Proben, Failover-Drills und ein Cutover-Fenster, das du wirklich kontrollierst.

7) Fazit: RDS ist ersetzbar – wenn man's richtig baut

RDS ist kein „magischer Managed-Dienst", sondern PostgreSQL mit Packaging. Und genau deshalb kannst du es ersetzen: Mit Proxmox als Plattform, einem HA-Pattern (Patroni oder CloudNativePG), einem sauberen Backup-/PITR-Konzept und Observability ohne CloudWatch-Tax.

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

Auch auf Azure? Lies unseren Azure Database for PostgreSQL Guide.

Bereit, deine RDS zu migrieren?

Wir kümmern uns um alles – von der Einrichtung bis zum laufenden Betrieb. Unser Managed PostgreSQL bildet exakt ab, was du von RDS 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 RDS ohne Datenverlust. Wenn du wissen willst, wie dein konkreter RDS-Stack auf Proxmox aussieht (Sizing, HA-Pattern, Backup/PITR, Cutover-Plan), dann fordere eine Migrations-Analyse an.

Starte hier:

Exit AWS – Übersicht unserer AWS-Migrationsservices
AWS 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 RDS: Der ultimative Guide zu Managed PostgreSQL auf Proxmox