Von Supabase wechseln

Wenn du Supabase außer für die Datenbank auch für Auth, Storage, Edge Functions und Realtime nutzt, bedeutet ein Wechsel zu CapyDB, vier Produkte zu ersetzen, nicht eines. Das kann richtig sein – meist ist es das, wenn die App der Kopplung entwachsen ist –, aber es ist ein Projekt und kein Nachmittag.

Wenn du Supabase vor allem als gehostetes Postgres nutzt und der Rest nebensächlich ist, ist das eine geradlinige Migration, und der Rest dieser Seite ist für dich.

• -Dein Schema, deine Daten, Indizes, Constraints, Funktionen und Trigger
• -Extensions, über den Katalog, den du pro Zelle aktivierst
• -Deine Migrationen, egal welches Werkzeug sie erzeugt hat
• -Jede Client-Bibliothek, denn der Connection String ist eine normale postgres://-URL

Supabases Richtlinien auf Zeilenebene sind gegen dessen Auth-Schema und dessen JWT-Claim-Helfer geschrieben. Die gibt es außerhalb von Supabase nicht, also hinterlässt ein reines Dump-and-Restore Richtlinien, die auf nicht vorhandene Funktionen verweisen.

Die CLI überführt sie. Der Konverter ist quelloffen, schreibt die Richtlinien gegen normale PostgreSQL-Sitzungseinstellungen um und meldet alles, was er nicht übersetzen konnte, statt still etwas auszugeben, das zu viel erlaubt.

capydb migrate rls ./supabase --out capyrls

• -Auth: auf einen dedizierten Identitätsanbieter wechseln und dieselben Claims in die Sitzungseinstellungen setzen, die deine überführten Richtlinien lesen
• -Storage: Objektspeicher plus signierte URLs; der Codemod bildet die Bucket-Semantik für die üblichen Fälle ab und meldet den Rest
• -Edge Functions: das, was deine Deployment-Plattform ohnehin ausführt – es sind gewöhnliche Serverless-Funktionen
• -Realtime: logische Replikation von PostgreSQL und LISTEN/NOTIFY stehen beide in einer Zelle zur Verfügung
• -Die Datenbank selbst: das ist der Teil, der wirklich ein reiner Umzug ist

Importiere direkt aus deinem Supabase-Connection-String. Der Importer kennt die Plattformschemata, die nicht mitreisen sollen, und filtert sie – du landest mit deinen Daten und nicht mit einer Kopie der Steuerebene eines anderen.

capydb import \
  --project my-app \
  --source-url "$SUPABASE_DATABASE_URL" \
  --follow

• -Mit Follow importieren und die Testsuite gegen die Zelle fahren, während die Quelle noch lebt
• -Die überführten Richtlinien anwenden und mit einer echten Sitzung testen, nicht mit einer Superuser-Verbindung
• -capydb doctor für Umgebungsvariablen ausführen, die noch auf das alte Projekt zeigen
• -Connection Strings je Umgebung tauschen, Logs beobachten, dann Follow stoppen
• -Die Quelle eine Woche schreibgeschützt stehen lassen - das kostet wenig und hat schon Leute gerettet

Sag uns vor einer Produktionsumstellung Bescheid. Wir sehen den Plan durch, sind im Fenster erreichbar und halten einen Wiederherstellungsweg bereit.