Aller au contenu principal

Supabase Migrations — Guide de lecture

Convention de nommage​

Format observé:

  • YYYYMMDDHHMMSS_description.sql

Exemple:

  • 20260329000000_add_monetization_tables.sql

Types de migrations rencontrés​

1) remote_schema​

  • Exemples: 20260220173718_remote_schema.sql, 20260311022127_remote_schema.sql
  • Usage: snapshots/alignements de schéma importés depuis l’état distant.
  • Note: certaines n’ont pas d’en-tête explicite en commentaire.

2) Migrations fonctionnelles​

  • Ajout de tables métier (contact_events, messages_vendeur, orders, payments)
  • Ajout de triggers et fonctions
  • Ajustements de rôles et règles métier

3) Migrations sécurité / RLS​

  • Politiques de lecture/écriture selon acteur
  • Correction de permissions publiques

Bonnes pratiques de revue​

  • Vérifier l’ordre d’exécution (dépendances FK, triggers, policies).
  • Vérifier cohérence de type (text vs uuid) avec schéma existant.
  • Vérifier idempotence (IF NOT EXISTS, DROP ... IF EXISTS quand pertinent).
  • Vérifier compatibilité avec RLS et clés de service.

Checklist avant supabase db push​

  1. Migration relue (FK, indexes, policies)
  2. Dry-run local ou environnement test
  3. Validation des types générés (database.types.ts)
  4. Contrôle des impacts frontend/backend

Commandes utiles​

cd packages/supabase
supabase db push --include-all --yes
supabase gen types typescript --linked --schema public > src/database.types.ts