PostgreSQL zu Supabase migrieren: Datenbank und Anwendung umstellen

Sie möchten eine produktive PostgreSQL-Datenbank nicht per Versuch und Irrtum umziehen? WZ-IT übernimmt die Supabase-Migration ab 3.490 € mit technischer Prüfung, Testlauf und geplantem Cutover.

Eine bestehende PostgreSQL-Datenbank zu Supabase zu migrieren ist grundsätzlich ein homogener Datenbankumzug. Beide Seiten verwenden PostgreSQL. Trotzdem ist die Migration mehr als das Austauschen einer DATABASE_URL: Rollen, Extensions, Eigentümer, Pooling, RLS und die Betriebsgrenzen der Zielplattform können das Verhalten der Anwendung verändern.

Die zentrale Entscheidung lautet außerdem: Soll nur die Datenbank umziehen oder soll die Anwendung anschließend Supabase Auth, Storage, Realtime, Edge Functions und die automatisch erzeugten APIs nutzen?

Was bei einer PostgreSQL-Migration übertragen wird

Mit pg_dump und pg_restore lassen sich typischerweise übertragen:

• Schemas, Tabellen und Daten
• Indizes, Constraints und Sequenzen
• Views und materialisierte Views
• Datenbankfunktionen und Trigger
• unterstützte Extensions
• RLS-Policies als Datenbankobjekte

Nicht blind übernommen werden sollten Eigentümer, Superuser-Rechte, providerinterne Rollen, Replikationsobjekte und plattformspezifische Extensions. Die offizielle PostgreSQL-Migrationsanleitung von Supabase empfiehlt deshalb Exporte ohne Ownership und Privilegien und verlangt eine anschließende Neuordnung der Rollen.

Quelle vorab prüfen

Vor der Migration erfassen wir mindestens:

Besonders wichtig sind Funktionen, die Dateisystemzugriff, eigene Background Worker oder Superuser-Rechte voraussetzen. Sie müssen vor dem Umzug ersetzt oder aus der Datenbank herausgelöst werden.

Welche PostgreSQL-Quellen dieser Pfad abdeckt

Der technische Grundweg gilt auch für verwaltete PostgreSQL-Angebote. Providerdetails werden entweder im Assessment oder in einem eigenen Leitfaden behandelt:

• selbst betriebene PostgreSQL-Datenbanken und On-Premise-Systeme
• Render Postgres, Railway Postgres und Fly Postgres
• Google Cloud SQL und Azure Database for PostgreSQL
• DigitalOcean Managed PostgreSQL, Aiven und vergleichbare Dienste
• AWS RDS und Aurora PostgreSQL
• Heroku Postgres
• Neon und früheres Vercel Postgres

Eine eigene Providerseite ist nur sinnvoll, wenn Netzwerk, Rollen, Branching, Add-ons oder Cutover tatsächlich eigenen Inhalt erzeugen. Ein bloßer Austausch des Markennamens wäre weder für Nutzer noch für Suchmaschinen hilfreich.

Dump und Restore oder logische Replikation?

Wartungsfenster mit Dump und Restore

Für überschaubare Datenbanken ist ein kontrollierter Export und Import meist der klarste Weg:

1. Zielprojekt und Extensions vorbereiten.
2. Testdump erstellen und in Supabase wiederherstellen.
3. Fehler, Rollen und inkompatible Objekte bereinigen.
4. Transferdauer und Validierungsabfragen dokumentieren.
5. Im Cutover Schreibzugriffe stoppen, final exportieren und umstellen.

Der Weg ist gut überprüfbar, benötigt aber eine zur Datenmenge passende Schreibpause.

Logische Replikation für einen kurzen Cutover

Supabase dokumentiert für PostgreSQL ab Version 10 auch logische Replikation. Sie eignet sich, wenn die Quelle weiter beschrieben werden muss, während die Grunddaten bereits übertragen werden. Voraussetzungen sind unter anderem geeignete Replikationsrechte, wal_level=logical, Replikationsslots und ein Replica Identity für veränderte Tabellen.

Nicht automatisch repliziert werden DDL-Änderungen, Sequenzen und Large Objects. Deshalb gehören Schema-Freeze, Sequenzabgleich und finaler Schreibstopp weiterhin in den Ablauf.

Rollen, RLS und APIs nach dem Import

Eine vorhandene PostgreSQL-Anwendung arbeitet häufig mit eigenen Login-Rollen oder einem zentralen Datenbanknutzer. Supabase ergänzt die Rollen anon, authenticated und service_role sowie PostgREST und Auth.

Nach dem Import ist deshalb zu entscheiden:

• Bleibt die Anwendung bei einer direkten PostgreSQL-Verbindung?
• Werden Tabellen über die Supabase Data API bereitgestellt?
• Welche Tabellen benötigen RLS?
• Welche Zugriffe laufen künftig mit Nutzer-JWTs?
• Welche Serverprozesse dürfen service_role verwenden?

RLS darf nicht nur formal vorhanden sein. Die tatsächlichen Nutzerwege müssen mit positiven und negativen Tests geprüft werden. Dafür steht eine eigene Anleitung zum Prüfen von Supabase RLS bereit.

Verbindung und Pooling umstellen

Supabase bietet direkte Verbindungen sowie Session- und Transaction-Pooling über Supavisor. Nicht jeder Modus passt zu jedem Framework:

• Migrationstools und langlebige Sessions benötigen den passenden Session-Modus oder eine Direktverbindung.
• Serverless-Anwendungen profitieren häufig von Transaction-Pooling.
• Prepared Statements und sessiongebundene Funktionen müssen gegen den gewählten Modus getestet werden.
• Firewall, IPv4-/IPv6-Erreichbarkeit und TLS gehören in die Abnahme.

Die Anwendung wird zuerst in einer Staging-Umgebung gegen Supabase getestet. Erst danach werden Produktions-Secrets und DATABASE_URL umgestellt.

Nur Datenbank oder vollständiges Supabase-Backend?

Ein PostgreSQL-Umzug kann bewusst auf die Datenbank begrenzt bleiben. Wenn zusätzlich Supabase-Funktionen eingeführt werden, entstehen weitere Arbeitspakete:

• bestehende Nutzerverwaltung zu Supabase Auth überführen
• Dateien in Supabase Storage migrieren
• Zugriffslogik als RLS modellieren
• REST-, GraphQL- oder Realtime-Zugriffe anbinden
• Jobs oder Backend-Code als Edge Functions oder externe Worker betreiben

Diese Erweiterungen sollten nicht stillschweigend als Teil eines Datenbankimports behandelt werden. Sie verändern die Anwendung und brauchen eigene Abnahmekriterien.

Abnahme und Rückfall

Eine belastbare Abnahme vergleicht nicht nur die Gesamtzahl der Datensätze. Geprüft werden:

• Zeilenzahlen und Stichproben kritischer Datensätze
• Constraints, Indizes, Sequenzen und Defaults
• Funktionen, Trigger und geplante Jobs
• Performance zentraler Queries
• Schreib- und Transaktionsverhalten
• Rollen, Grants und RLS-Negativtests
• Anwendung, APIs und Hintergrundprozesse

Der finale Ablauf orientiert sich an der Supabase-Migrationscheckliste. Nach erfolgreichem Cutover kann WZ-IT die Zielumgebung als Managed Supabase weiterbetreiben.

Quellen

• Supabase: Migrate from Postgres to Supabase
• Supabase: Database connection management
• PostgreSQL: Logical Replication