Le branching Supabase n'est pas une sauvegarde de vos données.

Vous avez activé le branching Supabase parce que cela ressemblait à la façon sérieuse de travailler. Il y a maintenant une branche de preview à côté de votre projet, les changements y sont essayés avant que quiconque les voie, et l'ensemble paraît nettement plus sûr que le mois dernier.

C'est effectivement plus sûr. Ce n'est simplement pas une sauvegarde, et la différence se voit exactement un jour.

Voici ce que les guides sur le branching passent sous silence : une branche est une seconde base de données à côté de la première, et non une version antérieure de celle-ci. Le branching est l'endroit où vous allez avant de faire un changement. Une sauvegarde est l'endroit où vous allez une fois que quelque chose a mal tourné. Activer le branching ne dépose une copie de vos données nulle part.

Le branching Supabase est-il une sauvegarde ?

Non. Une branche démarre comme une base vide habillée de votre schéma, et rien dans le branching ne remet en place un état antérieur de vos données.

La documentation de Supabase est directe là-dessus : « Les nouvelles branches ne démarrent avec aucune donnée de votre projet principal. Cela vise à mieux protéger vos données de production sensibles. » Une branche est construite à partir de vos migrations, et une migration décrit la forme d'une base de données. Les tables, les colonnes, les policies. Jamais les lignes.

La branche posée à côté de votre projet n'est donc pas la copie de mardi. C'est une base neuve qui n'a jamais vu vos utilisateurs.

Si vous n'avez jamais établi ce qui copie réellement votre base, c'est exactement la tâche vers laquelle cet article veut vous envoyer, et votre plan en règle l'essentiel en deux minutes.

Ce qu'une branche est réellement

Un second projet Supabase entier, avec tout ce qui va avec.

« Chaque branche est un environnement distinct avec sa propre instance Supabase et ses propres identifiants d'API », dit la documentation. Sa propre chaîne de connexion, ses propres clés, son propre Storage, ses propres comptes de connexion, ses propres lignes. Rien à l'intérieur n'est câblé au projet sur lequel vivent vos utilisateurs, et c'est précisément ce qui permet d'y casser des choses sans risque.

Cet isolement est toute la fonctionnalité, et c'est aussi pourquoi elle ne peut pas servir de sauvegarde. La copie de vos données que vous espériez n'a jamais été prise, et l'endroit où vous iriez la chercher est vide depuis le jour de sa création.

Ce qu'un merge fait, et ce qu'il ne fait pas

Il porte vos changements de schéma jusqu'en production. Il ne porte jamais de lignes, dans aucun sens, à aucun moment.

Quand vous mergez, Supabase applique les migrations de votre branche à votre base de production et déploie vos changements d'Edge Functions. C'est toute la cargaison. Une nouvelle table, une nouvelle colonne, une policy réécrite : cela voyage. Les lignes créées pendant vos tests restent dans la branche, et les lignes en production restent exactement telles qu'elles étaient, y compris celles que vous espériez remplacer.

Les gens attendent une version de cela qui n'existe pas : un merge qui irait piocher dans la production pour y remettre les choses en état. Ce que le branching a à la place, c'est un déploiement, appliqué vers l'avant, sur ce qui se trouve en production à ce moment-là.

Mais j'ai cloné mes données de production dans la branche

Alors vous avez une copie de vos lignes, et trois choses à propos de cette copie décident de ce qu'elle vaut le jour où vous en aurez besoin.

C'est possible et ce n'est pas obscur. La CLI Supabase décrit l'option comme le fait de cloner les données de production vers la base de la branche, et l'API de management prend la même option à la création d'une branche. Si vous l'avez utilisée, votre branche contient bel et bien vos données.

• Elle a été prise une fois. Le clone se produit à la création de la branche et rien ne le complète ensuite. Chaque commande, chaque inscription et chaque commentaire depuis vit en production et nulle part ailleurs, et c'est toute la différence entre une copie et un calendrier.
• Elle est dans le même compte. Une branche est un autre projet sous la même organisation, sur la même carte, derrière le même identifiant. Toutes les façons de perdre votre compte Supabase emportent la branche avec, et c'est un désastre différent de celui d'abîmer ses propres données.
• Personne ne l'a relue. Un clone à moitié terminé est indiscernable d'un clone abouti, vu de l'extérieur, jusqu'au moment où vous l'ouvrez.

La branche est la partie conçue pour disparaître

Une branche de preview est supprimée quand sa pull request est mergée ou fermée. C'est le comportement documenté de la fonctionnalité.

Supabase qualifie les branches de preview d'« éphémères et adaptées à des tests ciblés » et indique qu'elles « sont automatiquement supprimées lorsqu'une PR est mergée ou fermée ». L'autre catégorie, les branches persistantes, est « faite pour durer et recommandée pour des environnements comme le staging, la QA ou le développement », et celles-là survivent à la fermeture de la pull request.

Avec le réglage par défaut, la branche qui détient votre unique copie clonée est donc ce que votre flux de travail jette le jour où le travail se termine. La garder signifie la rendre persistante, et une branche persistante est un second projet Supabase qui tourne. Supabase propose le branching sur les plans payants et le facture par branche et par heure, sur leur page de prix.

À quoi le branching sert vraiment

À beaucoup de choses, et cet article serait malhonnête s'il ne le disait pas.

Une branche est l'endroit le moins cher pour découvrir qu'une migration supprime une colonne, avant qu'elle ne supprime la colonne où sont assis vos clients. Elle vous laisse répéter un changement de policy contre une base façonnée exactement comme la vôtre, avec ses propres clés, de sorte qu'une erreur n'atteint personne. Elle donne à une IA un endroit où avoir tort qui n'est pas votre application en production. Une sauvegarde ne fait rien de tout cela.

L'écart porte sur le type d'accident couvert. Le branching protège les changements qui passent par une pull request. L'essentiel de ce qui coûte réellement leurs données aux gens n'y passe jamais : une suppression dans l'éditeur de tables Supabase qui a touché plus de lignes que prévu, un script de seed pointé sur le projet en production, une migration écrite par une IA et validée à une heure du matin, un nettoyage de ce qui ressemblait à des données de test. Aucun de ces cas ne traverse une branche en route vers la production, et c'est la même raison qui fait que revenir en arrière sur le code ne ramène pas une table supprimée.

Ce second type d'accident est ce à quoi une sauvegarde répond. Elle se tient derrière vous dans le temps et détient l'état de votre base à un instant que vous pouvez nommer, pour qu'une erreur commise hors de votre flux de travail ait encore quelque part où revenir.

C'est aussi ce qu'est Reeve Care : des copies planifiées de votre base Supabase, conservées en dehors de votre compte Supabase, relues et vérifiées avant qu'aucune ne compte comme prise. Connectez vos buckets Storage et les fichiers déposés par vos utilisateurs voyagent avec, si bien qu'une restauration remet les lignes et les images vers lesquelles elles pointent.

Gardez le branching activé dans tous les cas. Rien de ce qui précède n'est un argument pour le désactiver.

Ce qu'il faut faire cette semaine

Avant de fermer cet onglet, ouvrez votre projet Supabase et regardez si quelque chose en prend une copie selon un calendrier. Cette seule réponse est tout le travail du jour, et le branching n'y change rien. La checklist sécurité en 10 minutes la couvre avec le reste de ce qu'il vaut la peine de vérifier sur une application fraîchement lancée, et ce que contient une copie et ce que fait vraiment le bouton de restauration est détaillé sur la page sauvegardes Supabase.