Tester une migration Postgres destructrice sur une branche de copie sur écriture
Quand l'utiliser : Vous avez une migration (DROP COLUMN, big UPDATE, reconstruction d'index) et vous souhaitez l'exécuter sur des données en forme de prod sans risquer la prod.
Prérequis
- Clé API Néon — console.neon.tech → Compte → Clés API
Déroulement
-
Créer une branche à partir du principalDans le projet Neon <id>, créez une branche nommée « test-drop-legacy » à partir de la branche principale. Renvoie la chaîne de connexion pour la nouvelle branche.✓ Copié→ Branche créée en <2 secondes, chaîne de connexion renvoyée
-
Appliquer la migration sur la brancheConnectez-vous à la nouvelle branche et exécutez : <coller la migration SQL>. Signalez le nombre de lignes et les erreurs éventuelles.✓ Copié→ La migration est terminée ; les comptes ont du sens
-
Vérifiez, puis nettoyezExécutez des requêtes d’intégrité sur les tables modifiées. Si les résultats semblent corrects, dites-le-moi et je postulerai au principal. Supprimez ensuite la branche dans tous les cas.✓ Copié→ Vérification + succursale supprimée pour éviter les frais de stockage
Résultat : Soyez assuré que votre migration fonctionne sur des données réelles, sans aucun risque pour la production.
Pièges
- La branche consomme de l'espace de stockage proportionnel à la quantité que vous écrivez dessus — Supprimez les branches rapidement après les tests : les branches abandonnées avec de nombreuses écritures font grimper la facture
- La branche est un instantané - ne voit pas les écritures qui se produisent sur la branche principale après la création de la branche — Branche fermée pour postuler; ou utilisez Neon time-travel pour partir d'un horodatage spécifique