Sie möchten eine AWS-Datenbank kontrolliert in eine Supabase-Zielarchitektur überführen? WZ-IT bietet die Supabase-Migration ab 3.490 € nach technischer Einordnung von RDS, Aurora und den verbundenen Anwendungen an.
Bei einer Migration von AWS RDS oder Aurora PostgreSQL zu Supabase ist der Datenbankkern kompatibel, das Betriebsmodell aber deutlich anders. AWS-spezifische Rollen, Parametergruppen, IAM-Verbindungen, VPC-Regeln und abhängige Dienste lassen sich nicht durch einen reinen PostgreSQL-Dump abbilden.
Deshalb wird zunächst getrennt, was wirklich in der Datenbank liegt und welche Funktionen von der AWS-Umgebung bereitgestellt werden.
RDS und Aurora unterscheiden
Vor dem Umzug werden Engine und Nutzung eindeutig bestimmt:
- RDS for PostgreSQL
- Aurora PostgreSQL-Compatible
- Aurora Serverless
- Read Replicas oder Aurora Reader
- Multi-AZ- und Failover-Konfiguration
- RDS Proxy oder andere Connection Pools
- IAM Database Authentication
- AWS Database Migration Service
Supabase ersetzt nicht automatisch die gesamte AWS-Architektur. Die Zielplanung muss klären, ob nur PostgreSQL, ein vollständiges Supabase-Backend oder zusätzlich die Anwendung und weitere AWS-Dienste umziehen.
Technisches Assessment der Quelle
| Bereich | Typische RDS-/Aurora-Frage |
|---|---|
| Netzwerk | Private Subnetze, Security Groups, Peering, VPN und erlaubte Transferpfade |
| Rollen | rds_superuser, Eigentümer, IAM Auth und providerinterne Rollen |
| Extensions | Verfügbarkeit und Versionsgleichheit auf Supabase |
| Parameter | Abweichungen in Parametergruppen und wal_level |
| Daten | Größe, Schreiblast, große Objekte und Partitionierung |
| Verfügbarkeit | Read Replicas, Multi-AZ, Failover und Downtime-Ziel |
| Integrationen | Lambda, S3, EventBridge, Secrets Manager, CloudWatch und Glue |
Aurora verhält sich für viele SQL-Workloads wie PostgreSQL, besitzt aber eigene Betriebs- und Skalierungsfunktionen. Diese werden nicht als Datenbankobjekte exportiert.
Sicherer Transferweg
RDS liegt häufig nur in privaten Subnetzen. Für Test und Cutover ist deshalb ein kontrollierter Netzwerkpfad nötig. Mögliche Wege sind:
- temporäre Migrations-VM im AWS-VPC
- VPN zwischen AWS und der Zielumgebung
- gezielte zeitlich begrenzte Freigaben
- Transfer über verschlüsselte Dump-Dateien
- logische Replikation mit eingeschränkten Endpunkten
Zugangsdaten werden nur für den notwendigen Zeitraum bereitgestellt und nach der Migration rotiert. Eine produktive Datenbank sollte nicht pauschal ins Internet geöffnet werden.
Dump und Restore
Für ein planbares Wartungsfenster kann die Datenbank mit nativen PostgreSQL-Werkzeugen übertragen werden. Der Testlauf prüft:
- ob alle Extensions auf Supabase verfügbar sind
- ob RDS-interne Rollen oder Eigentümer im Dump auftauchen
- ob Funktionen auf AWS-spezifische Dienste zugreifen
- wie lange Export, Transfer und Restore dauern
- welche Datenbankgröße und IOPS das Ziel für den Import benötigt
Die offizielle RDS-Migrationsanleitung von Supabase verwendet einen providerbereinigten Dump ohne Eigentümer und Privilegien.
Replikation und kurze Downtime
Bei hoher Schreiblast kann eine Vorabübertragung mit anschließender logischer Replikation sinnvoll sein. Dafür müssen Parametergruppe, Replikationsrechte, Publikationen, Primärschlüssel und Netzwerkzugriff passen.
Auch bei laufender Replikation bleiben Cutover-Aufgaben:
- Schemaänderungen während der Migration einfrieren
- Sequenzen vor Umschaltung abgleichen
- nicht replizierte Objekte gesondert übertragen
- Schreibzugriffe kurz stoppen
- letzten Replikationsstand bestätigen
- Anwendung und Worker koordiniert umschalten
Eine pauschale Zusage „ohne Downtime“ wäre ohne diese Prüfung unseriös.
AWS-Abhängigkeiten der Anwendung
Nach dem Datenbankumzug können Anwendungen weiterhin in AWS laufen und Supabase extern anbinden. Bei einem vollständigen AWS Exit müssen weitere Komponenten bewertet werden:
- Lambda und serverseitige Jobs
- S3-Buckets und Upload-Pfade
- Secrets Manager und Parameter Store
- Cognito oder andere Identity Provider
- SQS, SNS und EventBridge
- CloudWatch Logs, Metriken und Alarme
- private DNS- und VPC-Endpunkte
Supabase Auth, Storage, Realtime und Functions können einzelne Funktionen übernehmen, sind aber keine automatischen 1:1-Ersatzprodukte.
Anwendung umstellen und validieren
Vor dem Cutover wird eine Staging-Version mit Supabase verbunden. Zu testen sind:
- direkter und gepoolter Datenbankzugriff
- TLS, Timeouts und Connection Limits
- Transaktionen und Prepared Statements
- kritische Lese- und Schreibpfade
- Jobs, Lambda-Aufrufe und Webhooks
- Rollen, Grants und RLS
- Backup und Wiederherstellung des Ziels
Der Ablauf folgt der Supabase-Migrationscheckliste. Soll die Plattform anschließend auf kontrollierter Infrastruktur laufen, ist auch die Migration von Supabase Cloud zu Self-Hosted relevant.
Nach dem Cutover
RDS oder Aurora bleiben während des vereinbarten Rückfallfensters unverändert verfügbar. Erst nach Datenabnahme, Performanceprüfung und Backup des Ziels werden Replikation, Snapshots und AWS-Ressourcen geordnet zurückgebaut.
WZ-IT kann die Zielplattform anschließend als Managed Supabase betreiben.
