Heroku Postgres zu Supabase migrieren: Datenbank und App entkoppeln
Timo Wevelsiep•Aktualisiert: 25.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
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.
Quellen
Lieber betreiben lassen?
Sie möchten Supabase nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
Supabase migrieren, absichern oder betreiben
Wir migrieren Supabase-Projekte und bestehende Backends wie Firebase, Lovable, PostgreSQL, MySQL oder Auth0, bauen die Zielumgebung auf und übernehmen auf Wunsch den laufenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Ja. Die Anwendung kann zunächst auf Heroku weiterlaufen und über eine neue PostgreSQL-Verbindung auf Supabase zugreifen. Latenz, TLS, Pooling und ausgehende Verbindungen müssen getestet werden.
Nein. Der dokumentierte Heroku-Pfad betrifft die PostgreSQL-Datenbank. Dynos, Worker, Scheduler, Redis und andere Add-ons benötigen eigene Zielkomponenten oder bleiben zunächst bestehen.
Supabase dokumentiert einen Export mit pg_dump und den Import über psql. Version, Extensions, Eigentümer und Datenbankgröße werden vorher geprüft.
Nur nach gesonderter Anwendungs- und Nutzermigration. Eine PostgreSQL-Migration allein stellt keine Auth-Provider, Sessions oder Benutzerflüsse um.
Eine Supabase-Migration beginnt bei 3.490 Euro netto. Ob nur die Datenbank oder auch Anwendung, Worker und weitere Heroku-Dienste betroffen sind, bestimmt den konkreten Umfang.
Mehr zu Supabase
- Was ist Supabase?
- Supabase Cloud vs. Self-Hosted
- Supabase Self-Hosting: Vorteile & Nachteile
- Supabase-Kosten: Cloud vs. Self-Hosted
- Supabase Cloud zu Self-Hosted migrieren
- Supabase-Projekt, Region oder Organisation migrieren
- PostgreSQL zu Supabase migrieren
- AWS RDS und Aurora zu Supabase migrieren
- Heroku Postgres zu Supabase migrieren
- Neon und Vercel Postgres zu Supabase migrieren
- MySQL und MariaDB zu Supabase migrieren
- Microsoft SQL Server und Azure SQL zu Supabase migrieren
- Firebase zu Supabase migrieren
- Lovable Cloud zu Supabase migrieren
- Auth0 zu Supabase Auth migrieren
- Supabase-Migrationscheckliste
- Supabase vollständig sichern
- Supabase Self-Hosted aktualisieren
- Supabase RLS prüfen
- Supabase auf Hetzner betreiben
- Supabase mit Coolify installieren
