Firebase-Wechsel einordnen: Supabase-Migration mit Daten, Auth und Anwendung oder Appwrite-Hosting und Betrieb prüfen. Erstgespräch vereinbaren.
Eine Firebase-Alternative sollte nach den tatsächlich genutzten Diensten ausgewählt werden. Dieser Vergleich betrachtet Supabase, Appwrite und ergänzend PocketBase für einen selbst verantworteten Backend-Betrieb. Die Auswahl ist eine technische Entscheidungshilfe, keine Rangliste aus Leistungstests. Stand: Oktober 2026.
Die kurze Antwort: Supabase ist ein Kandidat, wenn PostgreSQL das gewünschte Zielmodell ist. Appwrite ist ein Kandidat für ein Backend mit zusammenhängenden APIs für Auth, Daten, Dateien und Functions. PocketBase kommt nur mit einer gesonderten Bewertung seiner Betriebsgrenzen in die Auswahl. Die jeweiligen Eigenschaften und Grenzen sind unten mit den Primärquellen verknüpft.
Inhaltsverzeichnis
- Zuerst die genutzten Firebase-Dienste erfassen
- Supabase, Appwrite und PocketBase vergleichen
- Supabase vs Firebase betrifft auch das Datenmodell
- Auth und Storage getrennt übertragen
- DSGVO-Anforderungen am konkreten Aufbau prüfen
- Self-Hosting und Betrieb gemeinsam kalkulieren
- Migration anhand von Abnahmekriterien planen
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Zuerst die genutzten Firebase-Dienste erfassen
Firebase ist für die Auswahl kein einzelner Datenbanktyp. Selbst innerhalb eines Projekts können etwa Firestore, Realtime Database, Storage und Functions unterschiedliche Ressourcestandorte haben. Der tatsächliche Aufbau muss pro Dienst erfasst werden. Firebase-Standortmodell.
Unsere Empfehlung: Erstellen Sie vor dem Produktvergleich ein Dienstinventar. Kennzeichnen Sie für jede Funktion, ob sie erhalten, ersetzt oder entfernt werden soll. Dokumentieren Sie auch Abhängigkeiten außerhalb des Backends, statt nur den Datenbestand zu zählen.
| Inventar | Für die Zielwahl zu klären |
|---|---|
| Daten und Abfragen | Collections, Beziehungen, Schreibpfade und benötigte Suchabfragen |
| Nutzerzugänge | Login-Verfahren, Rollen, Mandanten und Wiederherstellung von Konten |
| Dateien | Referenzen, Zugriffsrechte, Aufbewahrung und Downloads |
| Hintergrundlogik | Ereignisse, Zeitpläne, externe APIs und Wiederholungen |
| Anwendung | Verwendete SDK-Aufrufe, Offline-Verhalten und Fehlerfälle |
| Betrieb | Verantwortliche für Änderungen, Sicherung und Wiederanlauf |
Ein verbreiteter Irrtum: Die Firebase Local Emulator Suite ist keine produktive Self-Hosting-Variante. Die Dokumentation schließt diese Verwendung wegen der Ausrichtung auf Tests ausdrücklich aus. Emulator-Grenzen.
Supabase, Appwrite und PocketBase vergleichen
Die Tabelle ordnet dokumentierte Eigenschaften ein. Die letzte Spalte ist unsere Prüffrage, kein Leistungsversprechen eines Produkts oder von WZ-IT.
| Kandidat | Dokumentierte Grundlage | Unsere Prüffrage |
|---|---|---|
| Supabase | Eigener Betrieb ist dokumentiert; Datenmigration aus Firestore führt nach PostgreSQL. Self-Hosting, Migrationsmodell | Soll ein relationales Zielmodell entstehen? |
| Appwrite | APIs für Auth, Databases, Storage, Functions und Realtime; eigener Betrieb ist vorgesehen. Funktionsübersicht, Self-Hosting | Passen APIs, Berechtigungen und Anwendungsintegration zum Bestand? |
| PocketBase | Eingebettetes SQLite, Auth, Echtzeit-Abonnements und API; die Dokumentation enthält eine Warnung für produktionskritische Anwendungen. Einführung | Ist das Einsatzgebiet begrenzt und können manuelle Migrationsschritte verantwortet werden? |
Für PocketBase gilt zum genannten Stand: Vollständige Rückwärtskompatibilität vor Version 1.0 wird nicht zugesichert. Die Herstellerwarnung macht eine pauschale Empfehlung für produktionskritische Backends unpassend. PocketBase-Einschränkung. Der Eintrag dient der Einordnung; daraus wird hier kein zusätzliches WZ-IT-Angebot abgeleitet.
Unsere Auswahlregel: Prüfen Sie Supabase zuerst bei einem gewünschten PostgreSQL-Ziel und Appwrite bei einem API-basierten Backend-Entwurf. Verwerfen Sie einen Kandidaten, wenn eine benötigte Funktion oder ihre verantwortbare Umsetzung ungeklärt bleibt. Eine größere Funktionsliste ersetzt keine Abnahme der eigenen Anwendung.
Supabase vs Firebase betrifft auch das Datenmodell
Cloud Firestore organisiert Dokumente in Collections und erlaubt verschachtelte Objekte sowie Subcollections. Das ist ein anderes Modell als relationale Tabellen. Firestore-Datenmodell.
Der dokumentierte Supabase-Migrationsweg bildet zunächst eine Collection auf eine PostgreSQL-Tabelle ab. Komplexere Strukturen können vor dem Import auf mehrere zusammenhängende Tabellen verteilt werden. Daraus folgt keine automatische fachliche Modellierung. Firestore-Migrationswerkzeuge.
Wir empfehlen, vor dem Import die fachlichen Schlüssel und Beziehungen festzulegen. Entscheiden Sie bewusst, welche verschachtelten Werte als JSON erhalten bleiben sollen und welche eine eigene Tabelle benötigen. Prüfen Sie anschließend repräsentative Abfragen und Änderungen einschließlich Löschfällen. Gleiche Datensatzanzahl ist dafür nur ein Kontrollpunkt.
Auch die Zugriffskontrolle braucht einen eigenen Entwurf: In Supabase greifen Datenbankrechte und PostgreSQL Row Level Security zusammen. Vorhandene Firebase-Regeln sollten deshalb anhand ihrer fachlichen Bedeutung geprüft werden. Supabase-RLS. Als Abnahmeregel empfehlen wir positive und negative Tests je Rolle und Mandant: Eine erlaubte Abfrage muss funktionieren, ein fremder Zugriff muss scheitern.
Auth und Storage getrennt übertragen
Für Firebase Auth und Firebase Storage gibt es eigene Migrationsanleitungen. Ein erfolgreicher Firestore-Import belegt daher noch keinen vollständigen Backend-Wechsel. Auth-Migration, Storage-Migration.
Bei Auth dokumentiert Supabase Nutzerexport, Import und die Sicherung der Firebase-Hash-Parameter. Für die Prüfung bestehender Passwörter und ihre Aktualisierung beim ersten Login verweist die Anleitung auf einen Middleware-Pfad. Daraus darf kein pauschales Versprechen abgeleitet werden, dass sämtliche Logins unverändert funktionieren. Auth-Verfahren.
Unsere Prüfliste trennt deshalb Nutzeridentität, Login, Berechtigung und Dateien. Ordnen Sie alte und neue IDs nachvollziehbar zu, prüfen Sie Konto-Wiederherstellung und ausgewählte Provider-Anmeldungen. Für Dateien empfehlen wir zusätzlich den Abgleich von Referenzen, Metadaten und Zugriffen aus der Anwendung. Funktionen und externe Integrationen bekommen eigene Abnahmepunkte.
DSGVO-Anforderungen am konkreten Aufbau prüfen
Die Suche nach einer „Firebase Alternative DSGVO“ lässt sich nicht durch den Produktnamen beantworten. Artikel 28 DSGVO regelt Anforderungen an die Auftragsverarbeitung, Artikel 32 die Sicherheit der Verarbeitung und Kapitel V Übermittlungen in Drittländer. Diese Prüfungen betreffen den konkreten Datenfluss und die beteiligten Stellen. DSGVO-Primärtext.
Unsere Empfehlung ist eine Datenflussliste für produktive Daten, Backups, Logs, E-Mail-Versand, Identitätsanbieter und Supportzugriffe. Dokumentieren Sie Verantwortliche und Verträge. Ein selbst betriebener Server in Deutschland ersetzt diese Prüfung ebenso wenig wie die Auswahl einer europäischen Region bei einem Cloud-Dienst. Die rechtliche Bewertung des konkreten Aufbaus gehört zu den zuständigen Datenschutz- und Rechtsverantwortlichen.
Self-Hosting und Betrieb gemeinsam kalkulieren
Bei selbst betriebenem Supabase liegen unter anderem Wartung, Sicherheitsupdates, Sicherung, Wiederherstellung und Überwachung beim Betreiber. Außerdem sind nicht alle Funktionen der verwalteten Plattform verfügbar, etwa verwaltete Backups, PITR und Branching. Supabase-Betriebsgrenzen. Appwrite dokumentiert ebenfalls eigene Aufgaben für Sicherheit, Backups und Updates beim Self-Hosting. Appwrite-Betrieb.
Unsere Kostenstruktur für den Vergleich enthält deshalb mehr als die Servermiete:
- Infrastruktur einschließlich Speicher, Datentransfer und Reserve.
- Pflege der Plattform, Überwachung und Bearbeitung von Störungen.
- Sicherung und überprüfbare Wiederherstellung.
- Externe Dienste für Kommunikation und Identitäten.
- Einmalige Anwendungsänderungen, Datenübertragung und Übergangsbetrieb.
Vergleichen Sie denselben Funktionsumfang und denselben Betrachtungszeitraum. Self-Hosting wird hier weder als kostenlos noch als automatisch günstiger eingeordnet. Bleiben benötigte Funktionen oder die Betriebsverantwortung offen, empfehlen wir, auch den Verbleib bei Firebase zu prüfen.
Migration anhand von Abnahmekriterien planen
Der folgende Ablauf ist unsere Planungsempfehlung:
- Bestand und Zielkandidat einschließlich verbleibender externer Dienste festlegen.
- Datenmodell, Identitäten und Berechtigungen mit repräsentativen Daten prüfen.
- Anwendungswege einschließlich Upload, Login und Hintergrundverarbeitung abnehmen.
- Führenden Datenbestand, Schreibstopp und abschließenden Abgleich definieren.
- Umschaltkriterien, Sicherung und Wiederherstellung dokumentieren.
- Rückweg für den Fall festlegen, dass im Ziel bereits neue Daten entstehen.
- Quelle erst nach fachlicher Abnahme und geklärter Aufbewahrung stilllegen.
Der Rückweg braucht mehr als einen zurückgesetzten Endpunkt: Legen Sie fest, wie neue Zieländerungen behandelt werden und welche Umgebung schreiben darf. Der bestehende Firebase-zu-Supabase-Guide vertieft den technischen Migrationspfad; dieser Vergleich dient der vorgelagerten Zielwahl.
Unser Vorgehen bei WZ-IT
Die Supabase-Migration umfasst die gemeinsame Betrachtung von Daten, Auth, Storage, Functions und Anwendung. Welche Bestandteile aus Firebase übertragen oder angepasst werden können, wird technisch geprüft. Für ein Appwrite-Ziel gibt es Installation, Hosting und Betrieb; daraus folgt keine ungeprüfte Zusage einer vollständigen Firebase-Migration zu Appwrite.
Für eine Anfrage sind die genutzten Firebase-Dienste, Login-Verfahren, Datenstrukturen, externe Integrationen und Anforderungen an den Zielbetrieb hilfreich. Migration und laufender Betrieb werden im passenden Umfang abgegrenzt.
Weiterführende Guides
- Firebase zu Supabase migrieren
- Supabase Cloud und Self-Hosting vergleichen
- Supabase-Migrationscheckliste
Ziel und Umfang klären: Supabase-Migration oder Appwrite-Hosting. Erstgespräch vereinbaren.
Quellen
- Firebase: Firestore data model
- Firebase: Local Emulator Suite
- Firebase: Product locations
- Supabase: Self-hosting
- Supabase: Firestore migration
- Supabase: Firebase Auth migration
- Supabase: Firebase Storage migration
- Supabase: Row Level Security
- Appwrite: Documentation
- Appwrite: Self-hosting
- PocketBase: Introduction and production warning
- EUR-Lex: GDPR, Articles 28, 32 and Chapter V
