Die Entscheidung zur Reparatur eines Supabase-Backends

Das klingt selbstverständlich, bis eine fehlerhafte Produktionsanwendung jeden Defekt wie einen Plattformfehler aussehen lässt. Ich habe Teams gesehen, die wegen eines fehlenden Index, der ein Dashboard ausbremste, eine sechswöchige Migration planten. Ich habe auch erlebt, wie sie monatelang Richtlinien für ein Datenmodell verfeinerten, das die Kunden versprochenen Berechtigungen nie ausdrücken konnte. Die Entscheidung braucht Belege aus dem laufenden System, nicht den Frust über den letzten Vorfall.

Prüfen Sie fünf Faktoren: Abfragekomplexität, RLS-Wildwuchs, Abhängigkeit von Edge Functions, Compliance-Anforderungen und erwartete Kosten. Keiner davon reicht allein. Eine komplexe Abfrage kann völlig gesund sein. Fünfzig Richtlinien können leichter zu prüfen sein als fünf vage. Eine niedrige Hostingrechnung kann teure manuelle Wiederherstellung verbergen. Entscheidend ist, ob sich jede Schwierigkeit vor Ort beheben lässt und ob das reparierte System noch für die erwartete Nutzung der kommenden zwei Jahre passt.

Reparieren Sie Defekte, solange die Architektur passt

Eine Reparatur ist die bessere Wahl, wenn die vorgesehenen Grenzen des Backends noch zum Produkt passen. Wenn PostgreSQL weiterhin ein sinnvolles führendes Datensystem ist, direkter Clientzugriff noch zur Anwendung passt und Supabase Auth, Storage oder Realtime die tatsächlichen Anforderungen erfüllen, ersetzt ein Plattformwechsel bekannte Defekte durch neue Unbekannte.

Ordnen Sie jede Beschwerde ein, bevor Sie über ein Ziel sprechen. Verwenden Sie vier Gruppen: Implementierungsfehler, fehlende Betriebsdisziplin, architektonische Unvereinbarkeit oder externe Anforderung. Ein fehlender Fremdschlüssel, ein offengelegtes Service-Role-Geheimnis und ein nicht indexiertes Richtlinienprädikat sind Implementierungsfehler. Schemaänderungen ausschließlich über das Produktions-Dashboard weisen auf fehlende Disziplin hin. Ein Ablauf mit langen CPU-intensiven Aufgaben passt womöglich nicht zu Edge Functions. Eine Vertragsklausel, die eine Bereitstellungsregion oder Auditkontrolle verlangt, die der gewählte Tarif nicht bietet, ist eine externe Anforderung.

Nur die letzten beiden Gruppen machen eine Migration wahrscheinlich. Die ersten beiden verlangen meist eine Reparatur. Diese Einordnung verhindert einen bekannten Fehlschlag: Ein Team migriert die Tabellen und baut beim anderen Anbieter dieselbe zu großzügige Autorisierung, fehlende Migrationen und schwache Überwachung wieder auf.

Die Reparatur gewinnt auch, wenn das Team keine geprüfte Zielarchitektur benennen kann. „Ein eigenes Backend“ ist kein Ziel. Dahinter steht die Pflicht, ein API-Framework, ein Identitätssystem, Datenbankhosting, eine Verbindungsstrategie, Objektspeicher, einen Runner für Hintergrundaufgaben, ein Geheimnissystem, einen Logging-Stack, ein Sicherungsverfahren und einen Bereitstellungsweg auszuwählen. Jede Entscheidung braucht eine zuständige Person. Solange diese Entscheidungen fehlen, besteht die Migrationsschätzung hauptsächlich aus Leerstellen.

Setzen Sie vor Arbeitsbeginn eine Grenze für die Reparatur. Zum Beispiel: Migrationshistorie wiederherstellen, Browserzugriff auf privilegierte Zugangsdaten entfernen, Autorisierungstests bestehen, die langsamsten Nutzerabläufe in ein vereinbartes Latenzbudget bringen und Wiederherstellungsübungen dokumentieren. Ergibt diese begrenzte Reparatur ein Backend, das das Team betreiben kann, fehlt der Migration der Geschäftsgrund. Wächst die Grenze ständig, weil jede Korrektur eine unvereinbare Annahme offenlegt, sprechen diese Belege für den Umzug.

Abfragekomplexität braucht Pläne statt Meinungen

Komplexes SQL rechtfertigt allein keine Migration. Unter Supabase läuft PostgreSQL. Dasselbe Schema und dieselben Abfragen bei einem anderen verwalteten PostgreSQL-Dienst beseitigen daher weder schlechte Joins und fehlende Indizes noch breite Zeilenabrufe oder einen zu gesprächigen Clientzugriff.

Beginnen Sie mit Belegen zur Arbeitslast. Die Supabase-Dokumentation empfiehlt pg_stat_statements, um häufige und teure Anweisungen zu finden. Erfassen Sie Aufrufe, gesamte Ausführungszeit, mittlere Ausführungszeit, Zeilen und die normalisierte Abfrage. Sortieren Sie nicht nur nach der mittleren Zeit. Eine Abfrage, die 40 Millisekunden dauert und eine Million Mal läuft, kann mehr Kapazität verbrauchen als ein Zwei-Sekunden-Bericht, der zweimal täglich geöffnet wird.

Diese Abfrage liefert eine brauchbare erste Auswahl:

select
  queryid,
  calls,
  round(total_exec_time::numeric, 1) as total_ms,
  round(mean_exec_time::numeric, 1) as mean_ms,
  rows,
  left(query, 180) as sample
from pg_stat_statements
where calls >= 20
order by total_exec_time desc
limit 25;

Die Ausgabe enthält eine Zeile pro normalisierter Anweisung mit Abfragekennung, Aufrufzahl, kumulierter Zeit, Durchschnitt, betroffenen Zeilen und einem gekürzten Beispiel. Speichern Sie das Ergebnis für einen repräsentativen Geschäftszeitraum. Eine ruhige Staging-Datenbank beweist wenig über den Produktionsverkehr.

Führen Sie für die Anweisungen mit dem größten Anteil an Latenz oder Datenbankzeit EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) mit sicheren, repräsentativen Daten aus. ANALYZE führt die Anweisung aus. Nutzen Sie für Schreibvorgänge deshalb eine Transaktion, die Sie zurückrollen können, und führen Sie den Befehl nicht blind in Produktion aus. Suchen Sie nach sequenziellen Scans großer Relationen, starken Abweichungen zwischen geschätzten und tatsächlichen Zeilen, wiederholten Schleifen, Datenträgerzugriffen und überlaufenden Sortierungen. Diese Befunde sprechen für Indizes, neu formulierte Prädikate, bessere Statistiken, schmalere Auswahlen oder ein verändertes Datenmodell.

Reparieren Sie, wenn wenige identifizierbare Pläne den Großteil des Problems verursachen und gewöhnliche PostgreSQL-Änderungen sie lösen. Ziehen Sie eine Migration in Betracht, wenn die Arbeitslast selbst nicht zur gewählten Dienstform passt: anhaltende Analysescans stören Transaktionen, benötigte Erweiterungen fehlen, das Verbindungsverhalten erfüllt das Nebenläufigkeitsmodell der Anwendung nicht oder Daten müssen nahe an einem anderen System liegen und die gemessene Netzwerkzeit dominiert die Anfragen.

Verwechseln Sie die Zahl der API-Anfragen nicht mit Abfragekomplexität. Ein von KI erzeugtes Frontend lädt oft eine Liste und fordert dann für jede Zeile zugehörige Daten an. Die Datenbank führt möglicherweise einfache Abfragen aus, während die Seite unter den Hin- und Rückwegen leidet. Den Zugriff in einer View, einer RPC-Funktion oder einem Server-Endpoint zusammenzufassen, ist eine Reparatur. Das unveränderte Muster zu verschieben, ändert nur den Empfänger der Latenzrechnung.

Testen Sie Reparaturen gegen eine Arbeitslast, nicht gegen eine handverlesene Abfrage. Zeichnen Sie einen reproduzierbaren Satz von Lese- und Schreibvorgängen für die am stärksten genutzten Abläufe auf, entfernen Sie persönliche Daten aus den Testdaten und führen Sie ihn vor und nach jeder Änderung aus. Erfassen Sie Median und langsame Antwortzeit, Datenbank-CPU, Verbindungszahl, gelesene Zeilen und Fehlerquote. Ein neuer Index, der einen Filter verbessert, kann Schreibvorgänge bremsen oder genug Speicher belegen, um die Kostenrechnung zu verändern. Eine materialisierte View kann einen Bericht beschleunigen und zugleich eine Aktualisierungsverzögerung einführen, die das Produkt nicht akzeptiert.

Verbindungsdruck braucht dieselbe Diagnose. Browserclients, Serverprozesse, Transaktionspooler und direkte Datenbanksitzungen verhalten sich verschieden. Zählen Sie aktive und wartende Sitzungen während Lastspitzen und ermitteln Sie, welcher Teil sie besitzt. Öffnet eine erzeugte Anwendung pro Anfrage eine neue Serververbindung, reparieren Sie die Wiederverwendung, bevor Sie mehr Rechenleistung kaufen. Wechseln Sie erst, wenn die geprüften Nebenläufigkeits- und Transaktionsanforderungen nach der Korrektur von Client und Poolkonfiguration weiterhin nicht passen.

RLS-Wildwuchs wird am Verhalten gemessen

RLS-Wildwuchs wird zum Migrationssignal, wenn niemand zuverlässig vorhersagen oder testen kann, wer jede Zeile lesen und ändern darf. Die reine Anzahl der Richtlinien sagt fast nichts. Ein größerer Satz enger Richtlinien kann sicherer sein als eine kompakte Richtlinie voller verschachtelter Mitgliedschaftsprüfungen und veränderbarer JWT-Claims.

Inventarisieren Sie Richtlinien aus der Datenbank, statt einem Diagramm zu vertrauen:

select
  schemaname,
  tablename,
  policyname,
  roles,
  cmd,
  permissive,
  qual,
  with_check
from pg_policies
order by schemaname, tablename, cmd, policyname;

Prüfen Sie die Ausgabe als Autorisierungsmatrix. Nennen Sie für jede zugängliche Tabelle und Operation die handelnden Rollen, die Zeilenbedingung, die Einfüge- oder Aktualisierungsprüfung und die erwartete Ablehnung. Markieren Sie doppelte Mitgliedschaftsabfragen, Richtlinien auf Basis nutzerveränderbarer Metadaten, breite true-Bedingungen, uneinheitliche Mandantenspalten und Tabellen, die ohne bewusste Richtlinie über die API zugänglich sind.

Der RLS-Leitfaden von Supabase trifft eine klare Unterscheidung, die viele erzeugte Anwendungen übersehen. Nutzer können raw_user_meta_data verändern, weshalb dort keine Autorisierungs-Claims hingehören. raw_app_meta_data lässt sich nicht vom Nutzer ändern und kann Autorisierungsdaten enthalten, obwohl JWT-Inhalte bis zur Token-Erneuerung veraltet bleiben können. Das ist keine unbedeutende Namensfrage. Speichern Sie eine Rolle im falschen Claim, kann ein Nutzer sich selbst Zugriff geben.

Leistungskorrekturen kommen nach der inhaltlichen Richtigkeit. Indexieren Sie Spalten, die in Richtlinienprädikaten vorkommen. Wenn die Semantik es erlaubt, lässt eine skalare Unterabfrage um auth.uid() den Planer einen Init-Plan erzeugen, sodass die Funktion nicht für jede Zeile ausgewertet wird. Behalten Sie explizite Filter in Anwendungsabfragen bei, selbst wenn eine Richtlinie dieselbe Mandantengrenze erzwingt, denn der Filter hilft dem Planer bei einem schmaleren Pfad. Keine dieser Änderungen repariert ein Autorisierungsmodell, das das Team nicht beschreiben kann.

Erstellen Sie Ablehnungstests, bevor Sie Richtlinien ändern. Führen Sie dieselben Auswahl-, Einfüge-, Aktualisierungs- und Löschversuche als anonymer Nutzer, gewöhnliches Mitglied, Mitglied eines anderen Mandanten, Administrator und gesperrtes Konto aus, sofern dieser Zustand existiert. Prüfen Sie erlaubte und verbotene Zeilen. Tests mit der Service Role ersetzen Nutzertests nicht, weil privilegierter Zugriff RLS umgehen kann.

Reparieren Sie RLS, wenn das Produkt ein stabiles Mandantenmodell hat und sich Richtlinien auf benannte, wiederverwendbare Prädikate mit vollständiger Testmatrix reduzieren lassen. Migrieren Sie oder fügen Sie eine eigene Autorisierungsschicht ein, wenn Berechtigungen von schnell veränderlichen Beziehungen abhängen, Entscheidungen Kontext außerhalb von PostgreSQL brauchen, Kunden Erklärungen verlangen, die das aktuelle Modell nicht liefern kann, oder jede neue Funktion Änderungen an Dutzenden unverbundener Richtlinien verlangt. Auch dann entfällt der Datenbankschutz nicht. Die primäre Entscheidung findet lediglich woanders statt.

Achten Sie bei Schreibvorgängen auf Eigentum. Eine Select-Richtlinie kann Zeilen anderer Mandanten korrekt ausblenden, während eine unvollständige with check-Bedingung einem Nutzer erlaubt, eine Zeile mit fremder Mandantenkennung einzufügen. Aktualisierungen brauchen sowohl eine Regel für die vorhandene Zielzeile als auch eine Regel für den erlaubten Inhalt der neuen Zeile. Testen Sie diese Wege getrennt. Erzeugte Anwendungen üben oft nur erfolgreiche Lesezugriffe aus, sodass eine Rechteausweitung beim Schreiben bis in Produktion überlebt.

Zentrale Hilfsfunktionen können wiederholte Prädikate verringern, aber auch Privilegien verbergen. Prüfen Sie Besitzer, Schema-Suchpfad, Ausführungsmodus und Berechtigungen jeder security definer-Funktion, die eine Richtlinie verwendet. Qualifizieren Sie Relationsnamen und halten Sie die aufrufbare Oberfläche klein. Kann das Team nicht erklären, warum eine Hilfsfunktion erhöhte Rechte hat, steigert ihre Ausbreitung im Schema das Risiko, statt das System zu vereinfachen.

Die Abhängigkeit von Edge Functions bestimmt den Umfang

Edge Functions sind wichtig, weil sie zeigen, wie viel des Backends über die Datenbank hinausgeht. Ein Projekt mit zwei Webhook-Handlern ist eine andere Migration als eines, bei dem jeder privilegierte Schreibvorgang, Zahlungsrückruf, geplante Job, jede E-Mail-Aktion und externe Integration durch Deno-Funktionen läuft.

Erstellen Sie ein Funktionsverzeichnis mit einer Zeile pro bereitgestellter Funktion. Erfassen Sie Aufrufer, Authentifizierungsmethode, Geheimnisse, Datenbankoperationen, externe Dienste, Timeout-Verhalten, Wiederholungsregel, Idempotenzverfahren, Bereitstellungsbefehl sowie durchschnittliche und maximale Aufrufe. Quelldateien zeigen kein Geheimnis in einem Anbieter-Dashboard und keinen externen Webhook, der Monate zuvor konfiguriert wurde.

Supabase beschreibt Edge Functions als TypeScript-Funktionen in einer Deno-kompatiblen Laufzeit. Das gibt dem Code etwas Portabilität, doch das Verhalten darum herum erfordert weiterhin Arbeit: Gateway-Routing, JWT-Verarbeitung, Umgebungsgeheimnisse, geplante Aufrufe, Logübertragung, Bereitstellung und regionale Ausführung. „Der Code ist TypeScript“ ist eine hilfreiche Tatsache, aber kein Migrationsplan.

Reparieren Sie, wenn Funktionen dünne Adapter sind. Eine gute Reparatur verschiebt Geschäftsregeln in gewöhnliche Module, prüft Eingaben an der Grenze, setzt explizite Zeitlimits für externe Aufrufe, macht Webhook-Verarbeitung idempotent und verlagert lange Arbeit in eine Queue oder einen Worker, der zur Dauer passt. Die offiziellen Grenzen betreffen Speicher, CPU-Zeit, Gesamtdauer, Anfrageleerlauf, Paketgröße und Zahl der Geheimnisse. Lesen Sie die aktuellen Grenzen des aktiven Tarifs, statt eine bald veraltete Zahl in ein Architekturdokument zu kopieren.

Eine Migration wird attraktiv, wenn eine Laufzeitgrenze zur normalen Arbeitslast gehört und nicht nur gelegentlich einen Defekt auslöst. Bildverarbeitung, große Dokumentkonvertierungen, lange KI-Aufgaben, schwere Datenexporte und dauerhafte Abläufe brauchen oft Worker mit gesteuerter Parallelität, beständige Queues und einen expliziten Wiederholungszustand. Sie können PostgreSQL und Auth bei Supabase behalten und nur diese Jobs verschieben. Eine Teilmigration entfernt die Einschränkung oft ohne Austausch der Datenbank.

Schätzen Sie den Umzug nach Abhängigkeit, nicht nach Dateizahl. Ein Zahlungs-Webhook mit 80 Zeilen und undokumentiertem Wiederholungsverhalten kann riskanter sein als zwanzig reine Lese-Endpoints. Fordern Sie für jede Funktion einen Vertragstest, der dieselbe Anfrage an alte und neue Implementierung sendet, vom Anbieter erzeugte Felder normalisiert und Status, Body, Datenbankeffekte und ausgehende Aufrufe vergleicht. Ohne diesen Prüfstand erfahren Teams durch Kundenmeldungen von semantischen Unterschieden.

Compliance kann technische Bequemlichkeit überstimmen

Compliance begründet eine Migration nur, wenn eine schriftliche Anforderung mit verfügbarem Dienst, Tarif, Konfiguration und Betriebsprozess nicht erfüllbar ist. Vage Sorge über regulierte Daten verschwendet Zeit. Eine unterschriebene Kundenklausel, Kontrollformulierung eines Prüfers oder gesetzliche Einschränkung liefert etwas Prüfbares.

Überführen Sie die Anforderung in eine Kontrollmatrix. Nennen Sie betroffene Daten, erlaubte Regionen, Verschlüsselungserwartungen, Aufbewahrungsdauer, Löschverfahren, Wiederherstellungsziel, Zugriffsregeln für Beschäftigte, Auditbelege, Fristen zur Vorfallmeldung, Unterauftragsverarbeiter und Vertragsdokumente. Ordnen Sie jede Zeile der Plattform oder Ihrem Team zu. Verwaltetes Hosting überträgt nie die ganze Verantwortung an den Anbieter.

Prüfen Sie die benötigten Kontrollen in den aktuellen Supabase-Tarifunterlagen und Vertragsdokumenten. Auditlogs, Logaufbewahrung, zeitpunktbezogene Wiederherstellung, Single Sign-on, Projektrollen, private Netzwerke, Regionswahl und Unterstützung regulierter Arbeitslasten können je nach Tarif und Vereinbarung variieren. Eine im aktuellen Tarif fehlende Kontrolle verlangt möglicherweise ein Upgrade statt einer Migration. Vergleichen Sie das Upgrade mit einem realistischen Ziel, das dieselben Beleg- und Supportpflichten einschließt.

Sicherungen brauchen besondere Aufmerksamkeit. Die Supabase-Dokumentation erklärt, dass Datenbanksicherungen nicht die über die Storage API gespeicherten Objekte enthalten, sondern nur deren Metadaten. Eine Datenbankwiederherstellung stellt ein gelöschtes Objekt daher nicht wieder her. Wenn Ihr Notfallplan annimmt, ein Knopf drehe beides zurück, ist der Plan falsch. Reparieren Sie ihn mit getrenntem Objektschutz und einer Wiederherstellungsübung oder wählen Sie eine Architektur mit passenden Wiederherstellungskontrollen.

Eine Migration ist gerechtfertigt, wenn der Anbieter die nötige Vereinbarung nicht unterzeichnen kann, die geforderte Region oder Netzwerkgrenze fehlt, die Belegaufbewahrung den Vertrag nicht erfüllt oder die Organisation Infrastruktur auf eine Weise kontrollieren muss, die der gehostete Dienst nicht zulässt. Notieren Sie vor dem Umzug die nicht erfüllte Kontrolle und den Nachweis des Ziels. Selbsthosting kann Kontrolle geben, macht das Team aber auch für Patches, Überwachung, Sicherungsintegrität, Zugriffsprüfungen und Vorfallbelege verantwortlich.

Nutzen Sie eine Migration nicht, um das Verständnis der Datenflüsse zu vermeiden. Für den sicheren Umzug brauchen Sie dasselbe Verzeichnis: Tabellen, Objekt-Buckets, Authentifizierungsdatensätze, Logs, Geheimnisse, Replikate, Analyseexporte und externe Verarbeiter. Compliance-Arbeit deckt häufig undokumentierte Flüsse auf. Diese Entdeckung kann zu einer kleineren Reparatur führen oder bestätigen, dass der aktuelle Entwurf geändert werden muss.

Erwartete Kosten schließen Menschen und Übergangsrisiken ein

Die Kostenprognose sollte das reparierte System, den stabilen Zustand nach der Migration und den Übergang selbst unter derselben Nachfrageprognose vergleichen. Die heutige Supabase-Rechnung der Datenbankzeile eines anderen Anbieters gegenüberzustellen, erzeugt eine Fiktion.

Modellieren Sie Kosten nach Lasttreiber. Verwenden Sie monatlich aktive Nutzer, soweit sie Authentifizierung beeinflussen, Wachstum von Datenbankrechenleistung und Speicher, ausgehenden Verkehr nach Quelle und Ziel, Realtime-Nachrichten und Verbindungsspitzen, Storage-Volumen und -Operationen, Aufrufe von Edge Functions, Logvolumen und Aufbewahrung, Sicherungs- oder Wiederherstellungsfunktionen, Support und benötigte Tarifoptionen. Holen Sie die aktuellen Stückpreise beider Anbieter zum Entscheidungszeitpunkt ein. Halten Sie jeden Preis und jede enthaltene Quote mit Datum in einem Annahmenblatt fest, weil sich Preise ändern.

Verwenden Sie statt einer scheinbar genauen Prognose drei Nachfrageszenarien: erwartet, hoch und schrumpfend. Die Formel kann einfach bleiben:

monthly platform cost =
  base plans
  + database compute and storage
  + network egress
  + authentication usage
  + realtime usage
  + function usage
  + logs, backups, and support

monthly operating cost =
  engineering hours
  + incident response
  + security and compliance work
  + vendor management

Schätzen Sie Entwicklungsstunden anhand der tatsächlichen Arbeit: fehlgeschlagene Bereitstellungen, manuelle Richtlinienprüfungen, Datenbankoptimierung, Funktionsdebugging, Wiederherstellungstests und Supporteskalationen. Setzen Sie Arbeit, die ein Gründer übernimmt, nicht mit null an. Sie verzögert trotzdem Produkt- und Vertriebsarbeit.

Zu den Übergangskosten gehören parallele Umgebungen, Daten- und Objektkopie, Änderungserfassung bei Bedarf, Doppelwrites bei ihrer Wahl, Vertragstests, Clientaktualisierungen, Beobachtbarkeit, Sicherheitsprüfung, Unterstützung beim Wechsel und Rückkehrmöglichkeit. Ergänzen Sie die Umsatz- oder Vertragsexposition durch Ausfall und uneinheitliche Daten als Bandbreite, nicht als erfundene exakte Zahl. Eine Migration, die monatlich einige Hundert spart, kann sich erst nach Jahren rechnen.

Berechnen Sie den Monat der Kostendeckung:

break_even_month =
  transition_cost /
  (repaired_monthly_cost - migrated_monthly_cost)

Ist der Nenner null oder negativ, sprechen die Kosten nicht für die Migration. Liegt das Ergebnis jenseits der wahrscheinlichen Nutzungsdauer der Architektur, bleibt die Ersparnis theoretisch. Rechnen Sie erneut mit hoher Nachfrage, da ein Ziel womöglich erst ab einer Schwelle günstiger wird, und mit schrumpfender Nachfrage, weil feste Infrastruktur und Personal bei geringer Nutzung besonders teuer sind.

Reparieren Sie, wenn Tuning, Größenanpassung, Archivierung oder die Verlagerung einer Arbeitslast die Kurve ausreichend ändern. Migrieren Sie, wenn nach der Reparatur ein struktureller Kostentreiber bleibt, etwa unvermeidbarer ausgehender Verkehr, ein Premiumtarif hauptsächlich für eine Kontrolle oder Arbeitszeit zur Kompensation einer dauerhaften Plattformunvereinbarkeit.

Eine Punkteentscheidung legt schwache Annahmen offen

Eine Bewertungsmatrix hilft nur, wenn jede Note auf einen Beleg verweist. Sie darf Urteile nicht hinter Arithmetik verstecken. Verwenden Sie sie, um Annahmen sichtbar zu machen, die die Empfehlung ändern, und um offene Fragen zu markieren.

Bewerten Sie jeden Faktor für Reparatur und Migration von 0 bis 3. Null bedeutet, dass die Option die Anforderung nicht erfüllt. Drei bedeutet eine belegte Erfüllung. Behandeln Sie Compliance und Sicherheit als Ausschlussbedingungen: Kann eine Option eine Pflichtkontrolle nicht erfüllen, rettet ihre Gesamtpunktzahl sie nicht.

Verwenden Sie diese Faktoren:

1. Eignung für die Abfragelast, belegt durch Anweisungsstatistiken und Ausführungspläne.
2. Klarheit der Autorisierung, belegt durch Richtlinienverzeichnis und Ablehnungstests.
3. Eignung der Laufzeit, belegt durch das Verzeichnis der Edge Functions und Aufgabendauer.
4. Compliance-Eignung, belegt durch Kontrollmatrix und Vertragsdokumente.
5. Kosten im Prognosezeitraum einschließlich Übergang und Arbeit.

Ergänzen Sie Betreibbarkeit, Teamfähigkeiten, Qualität der Rückkehr und Lieferunterbrechung, wenn sie die Wahl ändern können. Notieren Sie neben jeder Bewertung einen Vertrauenswert. Eine Kostennote auf Basis eines Monats unvollständiger Nutzungsdaten sollte nicht gleichwertig mit einer durch einen unterzeichneten Vertrag bestätigten Compliance-Note aussehen.

Legen Sie Entscheidungsregeln vor der Bewertung fest. Eine praktische Regel lautet: reparieren, wenn alle Pflichtbedingungen erfüllt sind, der Reparaturumfang begrenzt ist und sich die Migration erst außerhalb des Prognosezeitraums rechnet. Migrieren Sie, wenn eine Pflichtbedingung ohne glaubwürdigen Plan scheitert oder mehrere gemessene Einschränkungen nach einer zeitlich begrenzten Reparatur bestehen bleiben. Wählen Sie eine Mischform, wenn ein Dienst, meist lange Berechnungen oder Analysen, den Großteil der Unvereinbarkeit verursacht.

Die Matrix stoppt auch Argumente mit versunkenen Kosten. Bisheriger Aufwand macht das aktuelle Backend nicht geeignet, und Ärger macht ein neues nicht geeignet. Belege können sich während der Prüfung ändern. Wenn zwei Indizes und ein korrigiertes Mandantenprädikat das angebliche Skalierungsproblem beseitigen, aktualisieren Sie die Note, ohne die ursprüngliche Migrationsidee zu verteidigen.

FixMyMess verbindet Codebase-Diagnose mit fachlicher Prüfung, um reparierbare Defekte in KI-erzeugten Anwendungen von einer Architektur zu trennen, die neu gebaut werden muss. Das kostenlose Codeaudit kann dieses erste begrenzte Verzeichnis liefern. Die Entscheidung bleibt bei den Verantwortlichen der Anwendung, besonders bei Verträgen, Risikotoleranz und künftiger Last.

Wechseln Sie nur mit erprobter Rückkehr

Eine Migrationsentscheidung ist unvollständig, solange das Team Datenbewegung, Prüfung, Umschaltung und Rückkehr nicht beschreiben kann. „PostgreSQL exportieren und importieren“ deckt nur einen Teil eines Supabase-Backends ab.

Inventarisieren Sie Datenbankschemas, Erweiterungen, Rollen, RLS-Richtlinien, Funktionen, Trigger, geplante Jobs, Auth-Nutzer und Identitätszuordnungen, Storage-Objekte und -Metadaten, Realtime-Abonnements, Edge Functions, Geheimnisse, Webhook-Registrierungen, DNS und jede Clientkonfiguration. Entscheiden Sie, was umzieht, bleibt oder entfernt wird. Bewahren Sie stabile Nutzerkennungen nach Möglichkeit oder ordnen Sie sie explizit zu, weil Autorisierungs- und Eigentumszeilen oft von ihnen abhängen.

Wählen Sie für ein kleines Produkt eine Migration mit Ausfallzeit, wenn ein Wartungsfenster akzeptabel ist. Sie lässt sich leichter durchdenken als Doppelwrites. Für einen Wechsel mit wenig Ausfallzeit erstellen Sie eine erste Kopie, replizieren spätere Datenbankänderungen, kopieren Objekte mit Prüfsummen, frieren Schemaänderungen ein, prüfen den Rückstand und planen die Umschaltung der letzten Schreibvorgänge. Doppelwrites aus dem Anwendungscode wirken sicher, erzeugen aber Konfliktregeln und Fehlerkombinationen, die viele kleine Teams nicht testen können.

Definieren Sie Abnahmeprüfungen vor dem Kopieren. Vergleichen Sie Zeilenzahlen pro Mandant und Tabelle, Summen oder Hashes ausgewählter stabiler Felder, verwaiste Datensätze, Objektzahlen und Prüfsummen, Ergebnisse von Richtlinientests, API-Vertragstests und eine Auswahl wichtiger Nutzerabläufe. Gesamtwerte können übereinstimmen, obwohl Eigentum falsch ist. Prüfen Sie deshalb Beziehungen und Zugriff mit echten Nutzerrollen.

Halten Sie die Quelle nach dem Wechsel für einen vereinbarten Zeitraum schreibgeschützt oder anderweitig wiederherstellbar. Definieren Sie den Rückkehrauslöser messbar: Fehlerquote, fehlende Datensätze, Authentifizierungsfehler, abweichender Zahlungsrückruf oder unvertretbarer Replikationsrückstand. Legen Sie fest, wer die Rückkehr auslösen darf und wie nach dem Wechsel entstandene Schreibvorgänge in das alte System gelangen. Ein Rückkehrplan, der neue Schreibvorgänge verliert, ist ein Notkompromiss und keine vollständige Rückkehr.

Nutzen Sie bei einer Reparatur dieselbe Disziplin in kleinerem Maßstab. Erstellen Sie eine geprüfte Sicherung, wenden Sie Migrationen über versionierte Dateien an, führen Sie Richtlinien- und Vertragstests aus, beobachten Sie Datenbank- und Anwendungsfehler und bereiten Sie eine umkehrbare Änderung vor, soweit PostgreSQL das erlaubt. Der Supabase-Migrationsleitfaden warnt, dass Änderungen im entfernten Dashboard die lokale Migrationshistorie umgehen. Holen Sie den vorhandenen Fernzustand, gleichen Sie die Historie ab und beenden Sie nicht erfasste Produktionsänderungen.

Die Authentifizierung braucht eine eigene Probe. Passwort-Hashes, Verknüpfungen sozialer Identitäten, Mehrfaktoranmeldung, Aktualisierungstoken, E-Mail-Vorlagen, Weiterleitungsregeln und Sitzungsdauer wechseln nicht automatisch mit den Tabellen. Entscheiden Sie, ob Nutzer aktive Sitzungen behalten, sich neu anmelden oder Zugangsdaten zurücksetzen. Testen Sie Einladung, Passwortwiederherstellung, Kontoverknüpfung und Kontolöschung am Ziel. Eine Migration ist fehlgeschlagen, wenn Profilzeilen erhalten bleiben, ihre Eigentümer aber ausgesperrt sind.

Storage braucht ebenfalls zwei Prüfungen. Vergleichen Sie zuerst Objektverzeichnis, Bytegröße, Inhaltstyp und Prüfsumme. Testen Sie dann den Zugriff so, wie die Anwendung ihn nutzt, einschließlich signiertem Zugriff, öffentlichen Objekten, Ersatz und Löschung. Datenbankzeilen können auf nie kopierte Objekte zeigen, während kopierte Objekte durch eine veränderte Bucket-Regel öffentlich werden können. Bewahren Sie Übertragungslogs lange genug auf, um eine Kundenmeldung nach dem Wechsel zu untersuchen.

Führen Sie eine Generalprobe mit einer aktuellen bereinigten Kopie durch und messen Sie jede Phase. Die Probe muss die Befehle, Verantwortlichen, Prüfpunkte und Abbruchbedingungen für den echten Tag liefern. Dauert die letzte Datensynchronisierung länger als das Wartungsfenster oder endet die Prüfung nicht vor der Wiederaufnahme der Schreibvorgänge, ändern Sie den Plan vor Produktion, statt auf schnelleres Arbeiten unter Druck zu hoffen.

Die Wahl ist bereit, wenn eine Option die Pflichtkontrollen bestanden, repräsentative Tests überstanden und unter glaubwürdigen Prognosen eine geringere Gesamtbelastung gezeigt hat. Hat keine Option das erreicht, untersuchen Sie weiter. Produktionsdaten belohnen kein Selbstvertrauen ohne Belege.