Soll Heroku Postgres planbar zu Supabase wechseln? WZ-IT übernimmt die Supabase-Migration ab 3.490 € nach Prüfung von Datenbank, Anwendung und Heroku-Abhängigkeiten.
Eine Migration von Heroku Postgres zu Supabase kann ein klar abgegrenzter Datenbankumzug oder Teil eines vollständigen Heroku Exits sein. Diese beiden Vorhaben dürfen nicht vermischt werden: Supabase übernimmt PostgreSQL und kann weitere Backend-Funktionen bereitstellen, ersetzt aber keine Heroku-Dynos und nicht automatisch jedes Add-on.
Zuerst den tatsächlichen Heroku-Scope bestimmen
Heroku-Anwendungen bestehen häufig aus mehreren gekoppelten Bausteinen:
- Web- und Worker-Dynos
- Heroku Postgres und gegebenenfalls Follower
- Redis oder Queue-Add-ons
- Heroku Scheduler
- Attachments einer Datenbank an mehrere Apps
- Config Vars und App-Secrets
- Log-, Monitoring- und E-Mail-Add-ons
- Domains, TLS und Pipelines
Die erste Entscheidung lautet daher: Zieht nur die Datenbank um oder die gesamte Anwendung? Eine App kann technisch auf Heroku verbleiben und Supabase als externe PostgreSQL-Datenbank nutzen. Ein vollständiger PaaS Exit benötigt zusätzlich ein neues Deployment- und Betriebsmodell.
Heroku Postgres prüfen
Vor dem Testexport werden erfasst:
| Bereich | Prüfung |
|---|---|
| Plan und Größe | Datenvolumen, Verbindungen, Schreiblast und Wartungsfenster |
| PostgreSQL | Version, Extensions, Schemas, Funktionen und Trigger |
| Rollen | Eigentümer, Grants und Heroku-spezifische Rollen |
| Verfügbarkeit | Follower, HA-Anforderungen und Rückfallweg |
| Anwendung | Framework, ORM, Pooling und direkte Datenbankzugriffe |
| Add-ons | Redis, Scheduler, Logging, ETL und externe Integrationen |
Bei größeren Datenbanken muss das Supabase-Ziel vor dem Import ausreichend Compute, Storage und IOPS erhalten. Supabase empfiehlt für größere Heroku-Datenbanken eine vorab passende Zielkapazität.
Testexport und Import
Die offizielle Anleitung von Supabase beschreibt den Transfer mit pg_dump und psql. Entscheidend sind unter anderem die Optionen ohne Eigentümer und Privilegien, weil Heroku und Supabase unterschiedliche verwaltete Rollen verwenden.
Ein Testlauf beantwortet:
- Lassen sich alle Extensions im Ziel aktivieren?
- Welche Rollen oder Eigentümer müssen neu gesetzt werden?
- Funktionieren Views, Trigger und Datenbankfunktionen?
- Stimmen Tabellen-, Zeilen- und Sequenzstände?
- Wie lange dauern Export, Transfer, Restore und Validierung?
- Welche Anwendungstests schlagen nach dem Wechsel fehl?
Erst aus diesem Lauf entsteht das belastbare Wartungsfenster.
Connection String und Anwendung
Heroku stellt Datenbankverbindungen üblicherweise über DATABASE_URL bereit. Nach dem Umzug ändern sich Host, Zugangsdaten, TLS und gegebenenfalls der Pooling-Modus.
Zu prüfen sind:
- Session- oder Transaction-Pooling
- Prepared Statements und ORM-Verhalten
- maximale Verbindungen je Dyno und Worker
- Netzwerkdistanz zwischen Heroku-Region und Supabase
- SSL-Modus und Zertifikatsprüfung
- Jobs, die mit separaten Datenbankrollen arbeiten
Die neue URL wird zuerst in einer Staging-App oder Heroku-Pipeline getestet. Ein bloßes Ersetzen der Produktionsvariable ohne Probelauf ist kein kontrollierter Cutover.
Was mit Dynos, Workern und Add-ons passiert
Supabase stellt Datenbank, Auth, Storage, Realtime, APIs und Edge Functions bereit. Daraus folgt aber keine automatische Zuordnung:
| Heroku-Baustein | Möglicher Umgang |
|---|---|
| Web-Dyno | Auf Heroku belassen oder separat neu deployen |
| Worker-Dyno | Externer Worker, Containerplattform oder gezielte Function |
| Heroku Scheduler | Cron, Workflow-System oder geplanter Datenbankjob |
| Redis | Weiterverwenden oder zu einem kompatiblen Dienst migrieren |
| Heroku Postgres | Zu Supabase PostgreSQL übertragen |
| Auth-Add-on | Eigenständig bewerten und gegebenenfalls zu Supabase Auth migrieren |
Bei einem reinen Datenbankumzug bleiben diese Komponenten unverändert. Bei einem vollständigen Heroku Exit werden sie als getrennte Arbeitspakete geplant.
Cutover mit Rückfallpunkt
Für einen Dump-und-Restore-Cutover ist der typische Ablauf:
- Wartungsmodus oder Schreibsperre aktivieren.
- Worker und Scheduler stoppen.
- finalen Export erstellen.
- Daten in Supabase importieren.
- Sequenzen, Mengen und kritische Datensätze prüfen.
DATABASE_URLund weitere Secrets umstellen.- App und Worker deployen und Smoke Tests durchführen.
Heroku Postgres bleibt während des Rückfallfensters unverändert erhalten. Neue Schreibvorgänge dürfen erst freigegeben werden, wenn klar ist, ob und wie ein Rückfall noch möglich wäre.
Supabase-Funktionen bewusst einführen
Der Datenbankumzug kann später um Supabase Auth, Storage, Realtime oder die Data API ergänzt werden. Diese Änderungen gehören nicht in einen vermeintlich einfachen PostgreSQL-Import. Für jeden Dienst werden Datenmodell, Berechtigungen, SDK und Nutzerwege separat getestet.
Die allgemeine PostgreSQL-zu-Supabase-Anleitung vertieft Dump, Replikation, RLS und Pooling. Für den Gesamtprozess steht die Supabase-Migrationscheckliste bereit.
WZ-IT kann Supabase nach dem Umzug als Managed Service weiterbetreiben.
