Sollte Ihr KI-erstelltes Backend Firebase verlassen?

Eine Anwendung sollte Firebase verlassen, wenn ihr Datenmodell, ihre Autorisierungsregeln oder ihre Serverabläufe schwerer zu verstehen sind als das Produkt selbst. Sie sollte nicht allein deshalb wechseln, weil das Team gehört hat, Postgres sei ernsthafter. Eine überstürzte Neuentwicklung kann bekannte Einschränkungen durch einen Ausfall, verlorene Konten und monatelang widersprüchliches Verhalten zweier Systeme ersetzen.

Für die meisten Teams, die über Firestore hinausgewachsen sind, bietet Supabase einen praktischen Mittelweg: relationale Daten, SQL, verwaltete Authentifizierung, Speicher, Funktionen und eine generierte API in einem Dienst. Ein verwalteter Postgres-Dienst gibt erfahrenen Teams mehr Kontrolle und macht weniger Plattformvorgaben, überlässt ihnen aber auch Authentifizierung, APIs, Dateispeicher, Hintergrundaufgaben, Beobachtbarkeit und Bereitstellung. Bei Firebase zu bleiben kann weiterhin richtig sein, wenn das Dokumentmodell passt und das Team seine Regeln und Funktionen reparieren kann, ohne ständig gegen die Plattform zu arbeiten.

Das Ziel folgt der Einschränkung, die Sie nicht länger bezahlen können

Wählen Sie das Ziel anhand der Einschränkung, die bereits Entwicklungszeit kostet. Wenn niemand sie in einem Satz benennen kann, ist das Team nicht bereit für die Migration. Eine vage Beschwerde wie „Firebase skaliert nicht“ ist keine Diagnose. Firestore kann große Lasten bewältigen; die nützliche Frage lautet, ob seine Zugriffsmuster und sein Konsistenzmodell noch zu dieser Anwendung passen.

Firebase passt weiterhin, wenn Clients hauptsächlich unabhängige Dokumente lesen und schreiben, Offline-Verhalten wichtig ist, Echtzeit-Listener zentral sind und Security Rules den Zugriff ohne duplizierten Geschäftszustand ausdrücken können. Für eine Migration spricht mehr, wenn eine Benutzeraktion mehrere zusammengehörige Datensätze ändern muss, Berichte Verknüpfungen zwischen Sammlungen brauchen, referenzielle Integrität in die Datenbank gehört oder Cloud Functions der einzige Ort geworden ist, an dem jemand die tatsächlichen Regeln versteht.

Supabase passt zu Teams, die Postgres-Semantik wollen, ohne jeden umgebenden Dienst aufzubauen. Es verringert die Zahl der Entscheidungen während des Umzugs. Das zählt, wenn ein KI-Werkzeug den bestehenden Code zusammengesetzt hat und niemand eine verlässliche Karte besitzt. Die Konventionen setzen zugleich Grenzen: Supabase Auth hat einen eigenen Lebenszyklus, die generierte Daten-API hängt von Sicherheit auf Zeilenebene ab und Plattformfunktionen sind nicht mit einem allgemeinen Anwendungsserver identisch.

Verwaltetes Postgres passt, wenn das Team bereits weiß, welches Web-Framework, welchen Identitätsanbieter, welches Aufgabensystem, welchen Speicherdienst und welche Überwachung es verwenden will. Die Datenbank ist portabel, doch das Team muss das Backend entwerfen und betreiben. Diese Freiheit besteht nur, wenn jemand die Entscheidungen verantwortet.

Nutzen Sie vor der Anbieterdiskussion eine einfache Punktetabelle. Geben Sie dem jeweils begünstigten Ziel einen Punkt:

Die Punktzahl trifft keine Entscheidung. Sie macht das Argument sichtbar. Jede Zeile, die niemand mit Belegen bewerten kann, wird vor der Migration zu einer Analyseaufgabe.

Migrationsaufwand steckt im Verhalten, nicht in der Anzahl der Datensätze

Eine Million einfache Dokumente kann leichter zu verschieben sein als zehntausend Dokumente, deren Bedeutung von Triggern, Client-Zeitstempeln, denormalisierten Zählern und Security Rules abhängt. Die Datensatzanzahl beeinflusst die Übertragungsdauer. Die Kopplung des Verhaltens bestimmt das Projekt.

Erfassen Sie zuerst jeden Pfad, der dauerhaften Zustand verändern kann. Nehmen Sie in einer KI-generierten Codebasis nicht an, dass der offensichtliche Datenbank-Client als Einziger schreibt. Browsercode kann direkt in Firestore schreiben, Serverrouten können das Admin SDK verwenden, geplante Funktionen können Zähler korrigieren, Webhooks können Zahlungszustände ändern und Bereitstellungsskripte können Dokumente anlegen. Suchen Sie nach SDK-Initialisierungen, Sammlungsnamen, aufrufbaren Funktionen, Zugriffen auf Speicherbereiche und Umgebungsvariablen. Vergleichen Sie diese Karte danach mit Produktionsprotokollen und der Cloud-Konfiguration. Eine reine Codesuche übersieht bereitgestellte Funktionen, die nicht mehr im Repository stehen.

Ordnen Sie jeden Schreibvorgang nach seiner erforderlichen Garantie ein. Eine Profiländerung verträgt meist eine direkte Aktualisierung. Eine Bestellbestätigung kann eine Transaktion, Idempotenz, ein unveränderliches Ereignis und eine Wiederholungsregel brauchen. Ein von einem Firestore-Trigger gepflegter Zähler kann zu einem SQL-Aggregat, einem Datenbank-Trigger oder einer asynchronen Projektion werden. Diese drei Entwürfe versagen unterschiedlich. Wer den Trigger Zeile für Zeile in eine neue Funktion kopiert, erhält eine alte Umgehungslösung, obwohl die neue Datenbank die ursprüngliche Einschränkung beseitigt hat.

Schätzen Sie die Arbeit in vier Gruppen: Datentransformation, Identitätsumstellung, Ablösung von Abläufen und Client-Integration. Zur Transformation gehören das Auflösen verschachtelter Dokumente, das Überführen wiederholter Werte in Tabellen, die Typwahl und der Umgang mit verwaisten Verweisen. Die Identitätsumstellung umfasst Passwort-Hashes, verknüpfte Anbieter, Sitzungen, E-Mail-Vorlagen, Weiterleitungsadressen und Kontowiederherstellung. Die Ablösung der Abläufe umfasst Funktionen, Warteschlangen, geplante Aufgaben, Webhooks und Speicherereignisse. Die Client-Integration umfasst geänderte Abfragen, Ladezustände, Offline-Annahmen, Fehlerbehandlung und Autorisierungsprüfungen.

Eine Inventardatei macht die Schätzung überprüfbar. Sie kann als einfaches JSON neben dem Migrationscode liegen:

{
  "source": "firestore",
  "collections": {
    "orders": {
      "writers": ["web-checkout", "payment-webhook"],
      "readers": ["account-page", "support-console"],
      "rules": ["owner-read", "support-read"],
      "side_effects": ["send-receipt", "increment-customer-total"]
    }
  }
}

Dieses Artefakt verhindert einen bekannten Fehler: Das Team migriert sichtbare Bildschirme, erklärt die Datenbank für fertig und entdeckt später, dass ein alter Webhook weiterhin nur in Firestore schreibt. Erfassen Sie jeden Schreiber, bevor Sie Termine festlegen. Wenn eine Sammlung einen unbekannten Schreiber oder ein unerklärtes Feld besitzt, ist die Analyse nicht abgeschlossen.

Ein Firestore-Export ist eine Quelle, kein Postgres-Schema

Der verwaltete Export von Cloud Firestore erzeugt LevelDB-Protokolldateien und Metadaten in Cloud Storage. Die Firebase-Dokumentation beschreibt ihn als Export, der in eine andere Firestore-Datenbank importiert oder unter bestimmten Bedingungen in BigQuery geladen werden kann. Er ist kein relationaler Dump für pg_restore und keine exakte Momentaufnahme vom Beginn des Vorgangs. Behandeln Sie ihn als Ausgangsmaterial für eine kontrollierte Transformation.

Die Migration benötigt eine ausdrückliche Zuordnung von Dokumentpfaden zu Tabellen. Ein Dokument wie customers/{customerId}/orders/{orderId} enthält in seinem Pfad eine Beziehung. In Postgres gehört diese Beziehung normalerweise in einen Fremdschlüssel orders.customer_id. Arrays einfacher Tags können Arrays bleiben. Arrays aus Objekten, die sich unabhängig ändern, werden meist zu untergeordneten Zeilen. Map-Felder können zu typisierten Spalten werden, wenn das Produkt sie abfragt, oder zu jsonb, wenn ihre Form tatsächlich offen ist. Jedes Dokument in jsonb abzulegen erleichtert den ersten Import und bewahrt die Schwächen des alten Modells.

Firestore erlaubt fehlende Felder und unterschiedliche Typen in verschiedenen Dokumenten. Postgres verlangt einen Typ und lässt das Schema ihn durchsetzen. Untersuchen Sie die Quelle vor dem Abschluss der Tabellen: Zählen Sie fehlende Felder, führen Sie beobachtete Typen auf, suchen Sie doppelte natürliche Bezeichner und finden Sie Verweise auf gelöschte Dokumente. Entscheiden Sie für jede Abweichung über die Behandlung. Eine stille Umwandlung, etwa eines ungültigen Zeitstempels in null, lässt den Import durchlaufen und verschiebt einen versteckten Fehler in die Produktion.

Für Supabase können Community-Werkzeuge zur Firebase-Migration Firestore-Sammlungen in JSON umwandeln und transformierte Daten importieren. Sie kennen jedoch nicht die von der Anwendung beabsichtigten Beziehungen. Für verwaltetes Postgres sind ein eigener Extraktor und Loader oft verständlicher. Machen Sie die Transformation in beiden Fällen deterministisch: Derselbe Quelldatensatz muss immer dieselbe Zielzeile und Kennung erzeugen. Behalten Sie eine Spalte mit der Quell-ID, bis der Abgleich abgeschlossen ist.

Ein nützliches Zielschema setzt die Aussagen durch, die die Anwendung bereits über ihre Daten macht. Dieses Fragment ordnet Bestellungen dauerhaft zu und verhindert Duplikate durch wiederholte Webhook-Zustellung:

create table customers (
  id uuid primary key,
  firebase_uid text unique,
  email text not null
);

create table orders (
  id uuid primary key,
  customer_id uuid not null references customers(id),
  provider_event_id text not null unique,
  status text not null check (status in ('pending', 'paid', 'cancelled')),
  created_at timestamptz not null
);

Gleichen Sie nach dem Laden Fakten ab, statt einem erfolgreichen Exit-Code zu vertrauen. Vergleichen Sie Anzahlen nach Geschäftskategorie, Geldsummen in der kleinsten Währungseinheit, früheste und späteste Zeitstempel, unterschiedliche Eigentümer und eine Stichprobe zugeordneter Quell- und Zieldatensätze. Bewahren Sie die Abfragen in der Versionsverwaltung auf. Eine Migration, die sich nicht wiederholen und prüfen lässt, bleibt eine einmalige Improvisation statt eines Veröffentlichungsprozesses.

Authentifizierung wird getrennt von Anwendungsdaten verschoben

Benutzerkonten sind keine gewöhnlichen Zeilen, denn ein gültiges Konto umfasst Anmeldedaten, Anbieteridentitäten, Prüfstatus, Sitzungen, Wiederherstellung und Verweise aus Anwendungsdaten. Die Migration einer users-Sammlung migriert Firebase Authentication nicht, auch wenn beide dieselbe UID verwenden.

Firebase CLI unterstützt auth:export, und Firebase stellt die für kompatible Importe nötigen Passwort-Hash-Parameter bereit. Der Supabase-Leitfaden zur Migration von Firebase Auth verwendet ein zweiteiliges Werkzeug: Es exportiert Firebase-Benutzer als JSON und importiert sie in die Zieltabelle auth.users. Der Leitfaden verlangt auch, die Firebase-SCRYPT-Parameter aufzubewahren, darunter Signierschlüssel, Salt-Trennzeichen, Runden und Speicherkosten. Dieses Detail entscheidet, ob Passwortbenutzer sich normal anmelden können oder alle eine Wiederherstellung durchführen müssen.

Gehen Sie nicht davon aus, dass jede Identität problemlos übertragen wird. Erfassen Sie Passwortkonten, E-Mail-Link-Konten, Telefonnutzer, anonyme Nutzer und jeden OAuth-Anbieter. Prüfen Sie, ob eine Person mehrere Anbieter unter einer UID verknüpft hat. Ermitteln Sie, ob das Ziel die Subjektkennungen der Anbieter behält und wie es doppelte E-Mail-Adressen behandelt. Benutzerdefinierte Claims brauchen einen ausdrücklichen Platz, etwa Autorisierungstabellen oder signierte Token-Claims. Sitzungen lassen sich normalerweise nicht zwischen unabhängigen Authentifizierungssystemen übertragen. Planen Sie daher Token-Ablauf, erneute Anmeldung und eine verständliche Benutzernachricht.

Drei Umstellungsmuster lassen sich vertreten. Ein erzwungenes Zurücksetzen ist am einfachsten, verursacht aber Supportaufwand und muss eine Produktentscheidung sein. Ein Massenimport der Hashes erhält die Passwortprüfung, wenn das Ziel Algorithmus und Parameter der Quelle unterstützt. Eine schrittweise Migration prüft die alten Anmeldedaten beim ersten Login, erstellt oder aktualisiert die Zielidentität und fragt das alte System für diesen Benutzer danach nicht mehr. Sie verringert den Umfang am ersten Tag, verlängert aber die Zeit, in der zwei Identitätssysteme Zugriff gewähren können.

Erstellen Sie unabhängig vom Muster eine unveränderliche Identitätszuordnung, bevor Sie Geschäftszeilen verschieben:

firebase_uid                         postgres_user_id
n7Yx...                              2d99150e-3b33-4afb-9c5b-7cbd20b91a4d

Verbinden Sie Datensätze während der Migration niemals anhand der E-Mail-Adresse. Menschen ändern Adressen, Anbieter normalisieren sie unterschiedlich und nach Jahren von Importen gibt es oft Duplikate. Nutzen Sie die Quell-UID als Migrationsidentität und hängen Sie dann die Ziel-ID an. Testen Sie deaktivierte und ungeprüfte Benutzer, gelöschte Benutzer mit verbliebenen Daten, reine Anbieterkonten und Kontowiederherstellung. Der erfolgreiche Standardfall eines Passwort-Logins beweist sehr wenig.

Autorisierung muss neu geschrieben und nicht übersetzt werden

Firestore Security Rules und Postgres-Sicherheit auf Zeilenebene beantworten ähnliche Fragen mit unterschiedlichen Ausführungsmodellen. Eine mechanische Übersetzung ist gefährlich. Firestore-Regeln bewerten eine Anfrage anhand von Dokumentpfaden und vorgeschlagenen Daten. Postgres-Richtlinien filtern Zeilen für SQL-Operationen, während Datenbankrollen und Rechte festlegen, auf welche Objekte ein Aufrufer zugreifen darf. Servercode mit privilegierten Zugangsdaten kann beide Systeme umgehen. Die Vertrauensgrenze zählt daher ebenso wie die Richtliniensyntax.

Schreiben Sie zuerst eine Zugriffsmatrix in der Sprache des Produkts. Legen Sie für jede Ressource fest, wer sie auswählen, einfügen, ändern und löschen darf und welche Felder oder Zustandsübergänge erlaubt sind. „Benutzer dürfen ihr Profil ändern“ ist unvollständig, wenn dieselbe Zeile ein Feld is_admin enthält. „Eigentümer dürfen Bestellungen ändern“ ist falsch, wenn Kunden status von pending auf paid setzen können.

Eine Supabase-Richtlinie für das Lesen eigener Bestellungen könnte so aussehen:

alter table orders enable row level security;

create policy "customers read own orders"
on orders for select
to authenticated
using (customer_id = auth.uid());

Diese Richtlinie funktioniert nur, wenn orders.customer_id dieselbe UUID speichert, die auth.uid() zurückgibt. Enthält die importierte Zeile eine Firebase-UID als Text und das neue Token eine Supabase-UUID, liefert die Richtlinie keine Zeilen. Deaktiviert ein Entwickler die Sicherheit auf Zeilenebene, damit der Bildschirm wieder funktioniert, kann sie alle Zeilen liefern. Identitätszuordnung und Schemadesign gehören deshalb zur Autorisierungsprüfung.

Verwaltetes Postgres stellt auth.uid() nicht bereit, solange die Anwendung keinen gleichwertigen Sitzungskontext erzeugt oder immer durch vertrauenswürdigen Servercode filtert. Viele Teams wählen die zweite Möglichkeit: Clients rufen eine API auf, die API prüft die Identität und SQL erhält die authentifizierte Benutzer-ID als Parameter. Dieses Modell lässt sich in einer Codebasis leichter prüfen, doch jeder Endpunkt muss die Autorisierung anwenden. Direkter Datenbankzugriff aus einem Browser verlangt strengere Rollen und Richtlinientests.

Testen Sie Ablehnungen und nicht nur erfolgreiche Vorgänge. Versuchen Sie für jede Rolle, die Zeile eines anderen Mandanten zu lesen, eine Eigentümerspalte zu ändern, einen geschützten Zustand zu aktualisieren, eine fremde Eigentümer-ID einzufügen und den Vorgang über jede öffentliche Route aufzurufen. Führen Sie diese Tests mit denselben öffentlichen Zugangsdaten und Token-Claims wie der Client aus. Eine Abfrage in der Verwaltungskonsole belegt keine Mandantentrennung.

Eigene Abläufe entscheiden, ob Supabase ausreicht

Supabase reicht meist aus, wenn das Anwendungsverhalten in SQL-Beschränkungen, Datenbankfunktionen, Edge-Funktionen, geplanten Aufgaben, Webhooks und einer überschaubaren Zahl von Hintergrundaufgaben leben kann. Verwaltetes Postgres wird klarer, wenn das Produkt lange laufende Worker, besondere Laufzeitumgebungen, komplexe Warteschlangen, private Netzwerke oder eine Bereitstellungskontrolle benötigt, die sich mit dem Funktionsmodell einer Plattform reiben würde.

Listen Sie bestehende Cloud Functions nach Triggertyp statt Dateiname auf. HTTP-Funktionen sind APIs. Aufrufbare Funktionen binden den Client an das Aufrufprotokoll von Firebase. Firestore-Trigger reagieren auf Datenänderungen. Authentifizierungs-Hooks reagieren auf Identitätsereignisse. Speicher-Trigger verarbeiten Dateien. Geplante Funktionen erledigen Wartung. Jede Kategorie braucht ein Ziel mit passendem Zustellungs- und Wiederholungsverhalten.

Achten Sie besonders auf eine Zustellung mindestens einmal. Ein Zahlungs-Webhook, ein Speicherereignis oder eine Warteschlangennachricht kann zweimal ankommen, auch wenn das selten passiert. Der neue Handler sollte die Ereignis-ID in derselben Transaktion beanspruchen, in der er den Zustand ändert. Die eindeutige Beschränkung im früheren Schema macht die zweite Zustellung zu einem erkennbaren Duplikat. Ein Flag im Arbeitsspeicher oder eine Protokollzeile liefert diese Garantie nicht über mehrere Instanzen hinweg.

Verschieben Sie nicht jeden Ablauf in einen Datenbank-Trigger, nur weil Postgres ihn ausführen kann. Trigger eignen sich für lokale Invarianten und kleine abgeleitete Änderungen, die dieselbe Transaktion teilen müssen. Sie eignen sich schlecht für Aufrufe fremder APIs, E-Mail-Versand oder langsame Medienverarbeitung. Solche Aktionen benötigen einen dauerhaften Auftrag und einen Worker, der idempotent wiederholt. Die Datenbank sollte Geschäftsänderung und Einreihen der Absicht gemeinsam festschreiben.

Die verbreitete Empfehlung, alles in SQL neu zu schreiben, wirkt attraktiv, weil sie Anwendungscode entfernt. Sie ist falsch, wenn sie Geschäftsabläufe in Funktionen versteckt, die der Rest des Teams weder bereitstellen noch verfolgen oder testen kann. Konsistenzregeln gehören nah an die Daten. Orchestrierung gehört in einen Dienst mit Protokollen, Zeitlimits, Wiederholungen und einer verantwortlichen Person. Supabase kann eine kleine Version dieses Dienstes aufnehmen; ein Entwurf mit verwaltetem Postgres setzt voraus, dass das Team ihn an anderer Stelle auswählt und betreibt.

Betriebsaufwand ist die Arbeit nach dem Start

Der betriebliche Unterschied lautet nicht „verwaltet oder nicht verwaltet“. Firebase, Supabase und verwaltetes Postgres betreiben Infrastruktur auf einer bestimmten Ebene. Der sinnvolle Vergleich fragt, welche Fehler bei Ihnen verbleiben und ob das Team sie erkennen und beheben kann.

Firebase beseitigt den Großteil der Datenbankverwaltung, doch das Team verantwortet weiterhin Security Rules, Indizes, Kontingente, Funktionsbereitstellungen, Kostenüberraschungen, Regionswahl und Wiederherstellung der Anwendung. Supabase verwaltet Postgres und bündelt mehrere Backend-Dienste, doch das Team verantwortet Schemamigrationen, Richtlinien auf Zeilenebene, Verbindungsverhalten, Abfrageleistung, Erweiterungskompatibilität und das Zusammenspiel der Plattformteile. Ein Anbieter für verwaltetes Postgres kümmert sich um den Datenbankprozess, Sicherungen und einen Teil der Wartung, während das Team die API-Schicht und jeden gewählten Begleitdienst besitzt.

Fragen Sie, wer fünf wiederkehrende Aufgaben übernimmt: eine Schemaänderung ohne Schäden an alten Clients anwenden, Daten auf einen bekannten Zeitpunkt zurücksetzen, auf durchgesickerte Server-Zugangsdaten reagieren, eine langsame Anfrage über Dienstgrenzen hinweg untersuchen und ein Authentifizierungsgeheimnis wechseln. Lautet die Antwort „ein Gründer, der die Bereitstellungskonfiguration nie gesehen hat“, ist verwaltetes Postgres plus eigener Dienstestapel ein zu großer erster Schritt. Betreibt ein erfahrenes Backend-Team diese Kontrollen bereits, können Plattformkonventionen stärker behindern als helfen.

Kostenvergleiche erfordern dieselbe Last und dieselben Fehlerannahmen. Firestore berechnet Vorgänge und Speicher nach seinem Modell. Postgres-Tarife bündeln häufig Rechenleistung und begrenzen dann Verbindungen, Speicher, Datenträger oder Durchsatz. Eine Abfrage, die ein relationales Aggregat liest, ist nicht mit einem Client vergleichbar, der Hunderte Dokumente abruft. Eine für Spitzenlast bemessene Postgres-Instanz ist nicht mit Leerlaufkosten eines serverlosen Dienstes vergleichbar. Spielen Sie produktionsähnliche Abfragen gegen ein Testziel und erfassen Sie Latenz, berührte Zeilen, Verbindungsnutzung und Abstimmungsaufwand. Ziehen Sie keine Schlüsse aus einer leeren Demo.

Auch Portabilität hat mehrere Ebenen. SQL-Tabellen wechseln leichter zwischen Postgres-Anbietern, als Firestore-Daten in ein relationales Schema gelangen. Supabase-spezifische Authentifizierung, Speichermetadaten, generierte APIs, Richtlinien und Edge-Funktionen verursachen dennoch Migrationsarbeit. Das ist vertretbar, wenn die Dienste heute mehr Arbeit sparen, als sie später kosten könnten. Die Aussage, ein Backend habe „keine Anbieterbindung“, verdeckt die Abhängigkeiten der Anwendung, auf die es ankommt.

Eine sichere Umstellung behält eine Autorität für jeden Schreibvorgang

Die sicherste Migration trennt das Kopieren der Daten vom Wechsel der Autorität. Während des Kopierens bleibt Firestore maßgeblich. Bei der Umstellung muss jede Geschäftseinheit genau einen maßgeblichen Schreiber haben. Wochenlanges Doppelschreiben ohne Abgleich erzeugt zwei plausible Wahrheiten und erschwert die Rückkehr.

Verwenden Sie diese Veröffentlichungsfolge als Ausgangspunkt:

1. Stoppen Sie Schemaänderungen und erfassen Sie jeden Leser, Schreiber, jede Funktion, Regel, jeden Index und jedes Geheimnis.
2. Bauen Sie Zielschema, Identitätszuordnung, Autorisierungstests und deterministischen Import in einer isolierten Umgebung.
3. Proben Sie eine vollständige Migration aus einem frischen Export, messen Sie die Dauer und gleichen Sie Geschäftsfakten ab.
4. Kopieren Sie die neuesten Daten, erfassen Sie Änderungen seit Kopierbeginn und pausieren Sie Quellschreibvorgänge für das letzte Delta.
5. Stellen Sie zuerst Serverschreiber und dann Clients um, beobachten Sie beide Systeme und behalten Sie einen getesteten Rückweg, bis neue Zielschreibvorgänge ihn unsicher machen.

Ein Plan mit geringer Unterbrechung kann Änderungserfassung oder vorübergehendes Doppelschreiben verwenden, braucht aber eine Konfliktregel und ein Abgleichsprotokoll. Erfassen Sie Quellvorgangs-ID, Zieltransaktion, Entität, Ergebnis und Wiederholungsstatus. Entscheiden Sie vorher, ob Quelle oder Ziel bei beidseitiger Änderung gewinnt. Wenn niemand erklären kann, wie ein fehlgeschlagener zweiter Schreibvorgang repariert wird, ist das Doppelschreiben nicht sicher.

Erhalten Sie nach Möglichkeit die Kompatibilität an der API-Grenze. Rufen Clients bereits eine Anwendungs-API auf, ändern Sie deren Speicherimplementierung und behalten den Vertrag. Sprechen Clients direkt mit Firestore, führen Sie eine Repository-Schicht oder eine neue API ein, bevor Sie jeden Bildschirm verschieben. Diese zusätzliche Trennung wirkt in der ersten Woche langsamer und erspart wiederholte Änderungen im weiteren Verlauf.

Definieren Sie die Rückkehr als getestetes Verfahren mit einer Frist. Bevor Zielschreibvorgänge beginnen, kann sie bedeuten, Clients zurückzulenken und das Ziel zu verwerfen. Sobald ausschließlich im Ziel vorhandene Datensätze entstehen, erfordert die Rückkehr eine umgekehrte Transformation oder einen Schreibstopp. Benennen Sie das genaue Ereignis, das das einfache Rückkehrfenster schließt. Eine Sicherung hilft, ist aber kein Rückkehrplan, solange das Team sie nicht wiederhergestellt und die Dauer gemessen hat.

Die Codebasis kann vor dem Backend-Umzug eine Reparatur brauchen

Eine Migration verstärkt alles, was die bestehende Anwendung nicht ausdrücklich macht. Generierte Projekte mischen oft Browser- und Server-Zugangsdaten, duplizieren Datenbankaufrufe in mehreren Komponenten, vertrauen vom Client gelieferten Eigentümer-IDs und verstecken Geschäftsregeln in UI-Ereignissen. Wer diese Aufrufe ohne neue Grenzen zu Supabase oder Postgres verschiebt, überträgt die Fehler.

Führen Sie die Migration erst nach Antworten auf vier Codefragen durch. Welche Module dürfen auf die Datenbank zugreifen? Wo wird serverseitige Identität zu einer vertrauenswürdigen Benutzer-ID? Welcher Dienst besitzt jeden Zustandsübergang? Welche Umgebung darf privilegierte Geheimnisse lesen? Wenn sich die Antworten von Bildschirm zu Bildschirm ändern, bauen Sie zuerst eine kleine Datenzugriffsgrenze. Sie muss nicht elegant sein. Sie muss alle Schreibvorgänge auffindbar und testbar machen.

Der Umgang mit Geheimnissen verdient eine eigene Prüfung. Die Firebase-Webkonfiguration identifiziert ein Projekt und wird durch Security Rules und Dienstkonfiguration geschützt, während Admin-SDK-Zugangsdaten privilegierten Zugriff gewähren. Supabase besitzt öffentliche Client-Zugangsdaten für die Arbeit mit Zeilenrichtlinien und privilegierte Server-Zugangsdaten, die normale Beschränkungen umgehen. Verbindungszeichenfolgen für verwaltetes Postgres gehören normalerweise auf einen Server und nie in Browsercode. Automatische Ersetzungen verwechseln diese Kategorien häufig, weil alle wie Umgebungsvariablen aussehen.

FixMyMess kann eine geerbte KI-Anwendung prüfen, ihre Authentifizierung und Logik reparieren, die Sicherheit härten, den Code überarbeiten und die Bereitstellung vor oder während eines Backend-Umzugs vorbereiten. Das nützliche Ergebnis ist kein Anbieterwechsel, sondern ein System, dessen Datenbesitz, privilegierte Pfade und Veröffentlichungsverfahren ein Mensch erklären kann.

Migrieren Sie keine Codebasis, die eine grundlegende Prüfung der Schreibpfade nicht besteht. Stabilisieren Sie Identität und Geschäftsinvarianten, wählen Sie das kleinste Ziel mit den nötigen Fähigkeiten und proben Sie, bis der Abgleich Routine ist. Firebase, Supabase und verwaltetes Postgres können alle ein solides Produkt betreiben. Keines davon liefert das fehlende Modell dafür, wie sich dieses Produkt verhalten soll.