Sie möchten Firebase nicht nur exportieren, sondern Anwendung und Berechtigungen belastbar auf Supabase umstellen? WZ-IT übernimmt die Firebase-zu-Supabase-Migration einschließlich Datenmodell, Auth, Storage, Functions, Test und Cutover.
Eine Migration von Firebase zu Supabase ist kein Austausch zweier gleich aufgebauter Datenbanken. Firebase kombiniert mehrere verwaltete Dienste und verwendet mit Firestore ein dokumentenorientiertes Modell. Supabase basiert auf relationalem PostgreSQL und setzt Berechtigungen über Datenbankrechte und Row Level Security durch.
Der größte Aufwand liegt deshalb häufig nicht im Kopieren der Daten, sondern im Übersetzen der Anwendungsarchitektur.
Welche Firebase-Dienste werden genutzt?
Vor der Zielplanung muss der tatsächliche Bestand erfasst werden:
- Cloud Firestore oder Realtime Database
- Firebase Authentication und externe Provider
- Firebase Storage
- Cloud Functions und Trigger
- Firebase Hosting
- Cloud Messaging und Push Notifications
- Analytics, Crashlytics und Remote Config
- App Check
- Extensions und angebundene Google-Cloud-Dienste
Supabase ersetzt nicht jeden Dienst eins zu eins. Für Messaging, Analytics oder Remote Config können ergänzende Plattformen oder eigene Services nötig sein.
Firestore und PostgreSQL denken unterschiedlich
Firestore speichert Dokumente in Collections und Subcollections. Beziehungen werden häufig durch eingebettete Objekte, IDs oder duplizierte Daten abgebildet. PostgreSQL arbeitet mit Tabellen, Primär- und Fremdschlüsseln, Constraints und Joins.
Eine reine Übernahme „eine Collection gleich eine Tabelle“ kann für einfache Daten funktionieren. Komplexe Anwendungen benötigen jedoch Entscheidungen:
| Firestore-Muster | Mögliches PostgreSQL-Ziel |
|---|---|
| eingebettetes Objekt | eigene Tabelle, JSONB oder Spalten |
| Subcollection | abhängige Tabelle mit Fremdschlüssel |
| duplizierte Referenzdaten | normalisierte Beziehung oder bewusste Materialisierung |
| Array von IDs | Join-Tabelle oder typisiertes Array |
| dynamische Dokumentfelder | definierte Spalten oder begrenztes JSONB |
| zusammengesetzte Firestore-Abfrage | SQL-Abfrage plus geeignete Indizes |
Das Zielmodell sollte anhand der tatsächlichen Schreib- und Lesewege entstehen, nicht nur anhand des Exports.
Daten exportieren und transformieren
Supabase stellt offizielle Firebase-Migrationsressourcen und Community-Werkzeuge bereit. Der dokumentierte Firestore-Weg kann Collections in JSON exportieren, transformieren und in PostgreSQL importieren.
Für eine produktive Migration gehören dazu:
- konsistenter Firebase-Export
- Mapping von Dokumenten auf das Zielschema
- Transformation von IDs, Zeitstempeln und Referenzen
- Import in Abhängigkeitsreihenfolge
- Prüfung von Zeilen, Beziehungen und Constraints
- Vergleich zentraler fachlicher Abfragen
Bei großen oder weiter beschriebenen Datenbeständen ist zusätzlich eine Strategie für Änderungen zwischen Erstexport und Cutover erforderlich.
Firebase Auth zu Supabase Auth
Die offizielle Auth-Migrationsanleitung beschreibt zwei Werkzeuge: Firebase-Nutzer werden in JSON exportiert und anschließend in auth.users importiert. Die Firebase-Parameter für Passwort-Hashes müssen dabei gesichert werden.
Zusätzlich zu prüfen sind:
- E-Mail- und Telefonnummern-Verifikation
- verknüpfte OAuth-Identitäten
- Custom Claims und Rollen
- gesperrte Nutzer
- MFA
- Passwort-Reset und E-Mail-Templates
- laufende Sessions und Token
Eine Migration sollte einen Test mit repräsentativen Konten je Provider enthalten. Für manche Sonderfälle ist ein geplanter Passwort-Reset oder eine Übergangslogik beim ersten Login sinnvoll.
Security Rules werden zu Grants und RLS
Firebase Security Rules und Supabase RLS verwenden unterschiedliche Modelle. Eine Regel wird deshalb nicht syntaktisch, sondern fachlich übersetzt.
Für jede Tabelle wird festgelegt:
- Welche Operationen darf
anonausführen? - Welche Operationen darf
authenticatedausführen? - Welche Zeilen gehören zum aktuellen Nutzer oder Mandanten?
- Welche serverseitigen Prozesse benötigen erhöhte Rechte?
- Welche Beziehungen müssen in einer Policy geprüft werden?
PostgreSQL prüft zunächst Grants und anschließend Policies. Beide Ebenen müssen stimmen. Der service_role umgeht RLS und darf ausschließlich in kontrollierten serverseitigen Komponenten verwendet werden.
Firebase Storage zu Supabase Storage
Die offizielle Storage-Migrationsanleitung arbeitet zweistufig: Dateien werden aus Firebase heruntergeladen und anschließend nach Supabase hochgeladen.
Zu migrieren sind:
- Bucket-Struktur und Objektpfade
- Dateien und Content Types
- Metadaten
- öffentliche oder private Sichtbarkeit
- signierte URLs und deren Verwendung
- Storage-RLS-Policies
Nach dem Upload sind Objektzahl, Größen und Stichproben oder Prüfsummen zu vergleichen. Alte Firebase-Download-URLs funktionieren nicht automatisch weiter.
Cloud Functions und Trigger neu zuordnen
Firebase Functions können auf unterschiedliche Ziele verteilt werden:
- Supabase Edge Functions
- PostgreSQL-Trigger und Datenbankfunktionen
- Webhooks
- Queue- oder Workflow-Systeme
- eigenständige Backend-Services
Dabei ändern sich Laufzeit, Authentifizierung, Secrets, Trigger und Fehlerbehandlung. Eine Function sollte nicht blind portiert werden, wenn PostgreSQL denselben Vorgang transaktional und einfacher abbilden kann.
Anwendung und SDK umstellen
Frontend und Backend verwenden nach der Migration andere Clients, URLs und Fehlerobjekte. Zu prüfen sind:
- Initialisierung und Umgebungsvariablen
- Datenabfragen und Pagination
- Realtime Listener
- Auth-Status und Token-Refresh
- Uploads und Download-URLs
- Offline-Verhalten
- serverseitige Admin-Zugriffe
- Push Notifications und andere verbleibende Firebase-Dienste
Eine Parallelphase mit automatisierten und manuellen Nutzerwegtests ist sicherer als ein sofortiger Austausch in Produktion.
Cutover mit klarer Grenze
Vor der Umschaltung müssen geklärt sein:
- Zeitpunkt der letzten Firebase-Schreibvorgänge
- finaler Daten- und Storage-Sync
- Verhalten aktiver Sessions
- Veröffentlichung der neuen App-Version
- Umgang mit alten Clients
- Rückfallfenster und Daten, die nach dem Cutover entstehen
Erst nach der Abnahme werden Firebase-Ressourcen kontrolliert stillgelegt. Backups und Exporte sollten für den vereinbarten Zeitraum erhalten bleiben.
