Migrer depuis Supabase

Si vous utilisez Supabase pour l’authentification, le stockage, les fonctions edge et le temps réel en plus de la base, passer à CapyDB signifie remplacer quatre produits, pas un. Ce peut être le bon choix - c’est généralement le cas quand l’application a dépassé ce couplage - mais c’est un projet, pas un après-midi.

Si vous utilisez surtout Supabase comme Postgres hébergé et que le reste est accessoire, c’est une migration directe et la suite de cette page est pour vous.

• -Votre schéma, vos données, index, contraintes, fonctions et déclencheurs
• -Les extensions, via le catalogue que vous activez par cellule
• -Vos migrations, quel que soit l’outil qui les a produites
• -Toutes les bibliothèques clientes, puisque la chaîne de connexion est une URL postgres:// normale

Les politiques de sécurité au niveau des lignes de Supabase sont écrites contre son schéma d’authentification et ses utilitaires de claims JWT. Cela n’existe pas hors de Supabase : un simple export-restauration vous laisse donc des politiques qui référencent des fonctions absentes.

La CLI les convertit. Le convertisseur est open source, réécrit les politiques contre des paramètres de session PostgreSQL standard et signale tout ce qu’il n’a pas pu traduire plutôt que d’émettre silencieusement quelque chose de trop permissif.

capydb migrate rls ./supabase --out capyrls

• -Authentification : passez à un fournisseur d’identité dédié, puis placez les mêmes claims dans les paramètres de session que lisent vos politiques converties
• -Stockage : stockage objet plus URLs signées ; le codemod transpose la sémantique des buckets pour les cas courants et signale le reste
• -Fonctions edge : ce que votre plateforme de déploiement exécute déjà - ce sont des fonctions serverless ordinaires
• -Temps réel : la réplication logique de PostgreSQL et LISTEN/NOTIFY sont toutes deux disponibles sur une cellule
• -La base elle-même : c’est la partie qui relève véritablement du simple transfert

Importez directement depuis votre chaîne de connexion Supabase. L’importeur connaît les schémas de plateforme qui ne doivent pas voyager et les filtre : vous repartez avec vos données, pas avec une copie du plan de contrôle de quelqu’un d’autre.

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

• -Importez en mode suivi et passez votre suite de tests sur la cellule pendant que la source est encore active
• -Appliquez les politiques converties et testez-les avec une vraie session, pas avec une connexion superutilisateur
• -Lancez capydb doctor pour les variables d’environnement qui pointent encore vers l’ancien projet
• -Remplacez les chaînes de connexion par environnement, surveillez les journaux, puis arrêtez le suivi
• -Laissez la source en place, en lecture seule, pendant une semaine - cela coûte peu et a déjà sauvé des gens

Prévenez-nous avant une bascule en production. Nous relirons le plan, serons présents pendant la fenêtre et garderons une voie de restauration prête.