Trois façons de sauvegarder une base Supabase, et ce qui manque

Tous ceux qui construisent sur Supabase finissent par poser la même question, en général une semaine après le lancement et le plus souvent à deux heures du matin : si je casse quelque chose, est-ce que je récupère mes données ?

La réponse dépend entièrement de la voie que vous avez prise parmi trois, et chacune laisse passer ce que les deux autres couvrent.

Laquelle choisir ?

Activez ce que votre plan Supabase vous donne, puis gardez une copie ailleurs. Ce sont deux travaux différents, et ne faire que le premier est exactement l'erreur que cet article existe pour éviter.

La sauvegarde du tableau de bord vous protège de vos propres erreurs. Une copie que vous détenez vous protège de la perte du compte : un paiement qui échoue, un projet suspendu, un mot de passe irrécupérable. Ce sont des catastrophes différentes et elles demandent des réponses différentes.

Ce que contient vraiment une sauvegarde

Vos tables, vos lignes, vos index et fonctions, et vos règles Row Level Security, c'est-à-dire les politiques qui décident qui a le droit de lire quoi, et pas seulement les tables auxquelles elles s'appliquent. C'est tout.

Ce qu'elle ne contient pas, c'est tout ce qui n'a jamais été dans la base :

Ce qui piège les gens, c'est Storage. Chaque avatar, chaque PDF téléversé, chaque image ajoutée par vos utilisateurs vit dans un stockage d'objets, pas dans la base : la base ne garde que le chemin de chaque fichier. Restaurez une sauvegarde dans un projet vide et vous obtenez une table pleine de liens vers des fichiers qui ne sont pas là.

Voie 1 : le tableau de bord Supabase

La plus simple, et celle que la plupart des gens devraient activer en premier. Supabase prend des sauvegardes quotidiennes sur les plans payants, et la restauration à un instant précis est disponible en option si vous devez revenir à une minute donnée plutôt qu'à minuit dernier.

Ce qu'elle fait bien : elle tourne sans vous, elle est complète, et restaurer tient en quelques clics dans une interface plutôt qu'en une commande à réussir sous pression.

Ce qui lui manque : la copie vit dans le compte. Si le projet est suspendu, si la carte enregistrée échoue ou si vous perdez l'accès à la connexion, les sauvegardes sont derrière la même porte que ce qu'elles protégeaient. C'est une sortie de secours à l'intérieur du bâtiment.

Elle n'existe pas non plus sur le plan gratuit, là où se trouvent la plupart des applications fraîchement lancées.

La formule sur laquelle vous êtes décide si vous avez cela ou non, et la vérification prend deux minutes.

Voie 2 : pg_dump sur votre propre machine

Supabase, c'est Postgres, donc l'outil standard de Postgres fonctionne. pg_dump écrit toute la base dans un fichier que vous détenez.

pg_dump "postgresql://…votre chaîne de connexion…" \
  --clean --if-exists --no-owner \
  --file backup-2026-08-09.sql

Ce qu'elle fait bien : c'est gratuit, c'est complet, le fichier est à vous, et vous pouvez le restaurer dans un projet tout neuf sur un autre compte. Des trois voies, c'est la seule qui survit à la perte de tout le reste.

Ce qui lui manque : elle n'arrive que quand vous y pensez. Ce n'est pas un détail technique, c'est tout le défaut. Le dump sur votre portable porte la date du jour où vous y avez pensé pour la dernière fois, et le jour où vous en avez besoin n'est jamais un jour où vous y pensiez.

Il y a un second problème, plus discret : un dump non testé est une supposition. Un fichier écrit pendant qu'une migration était à moitié appliquée, ou tronqué en silence parce que la connexion a lâché, ressemble exactement à un bon fichier jusqu'au jour où vous essayez de vous en servir.

Voie 3 : les sauvegardes gérées

Quelque chose d'autre prend la copie selon un horaire, la range hors de votre compte et, la partie qui compte vraiment, vérifie que la copie est réelle avant de la déclarer faite.

C'est ce que fait Reeve Care : plusieurs copies par jour selon le plan, chiffrées et conservées hors de votre compte Supabase, chacune vérifiée en comptant ce qui est sorti face à ce qui est entré. Une sauvegarde ne compte comme prise qu'une fois vérifiée, et c'est pourquoi la date affichée dans le tableau de bord est celle de la dernière copie vérifiée et non du dernier essai.

Le compromis honnête : cela coûte de l'argent, et c'est un service de plus dans votre pile. Si vous êtes assez discipliné pour tenir la voie 2 selon un vrai calendrier et tester les restaurations, vous n'en avez pas besoin.

Tout le cycle est détaillé sur la page des sauvegardes Supabase : la copie qui quitte Supabase, la vérification qui suit, et le bouton qui la remet en place.

Avez-vous déjà restauré une sauvegarde ?

Cette question décide si vous avez une sauvegarde ou un fichier que personne n'a jamais ouvert. Un dump que personne n'a relu est une supposition sur l'avenir, et le moment où vous découvrez qu'elle était fausse est le moment où vous aviez besoin qu'elle soit vraie.

Un test de restauration n'a rien de spectaculaire. Créez un nouveau projet Supabase, chargez-y votre sauvegarde la plus récente, ouvrez l'application sur ce projet et vérifiez qu'une ligne que vous reconnaissez est bien là. Une demi-heure, une fois par trimestre. Si la restauration échoue, vous l'apprenez un mardi après-midi plutôt qu'au milieu d'une panne.

Si vous voulez la liste plus large de ce qui mérite un contrôle sur une application fraîchement lancée, la checklist sécurité en 10 minutes couvre les sauvegardes avec le reste, et le guide de sécurité Supabase passe en revue ce qui reste couramment ouvert.

Que faire cette semaine

À lire ensuite : si vous pensiez que l'annulation de votre builder couvrait vos données, l'historique des versions n'est pas une sauvegarde est le premier à lire. Ensuite, votre base de données n'est privée que dans la mesure des clés placées devant, et quelles clés d'API sont sûres dans votre frontend traite de celle qui contourne toutes les règles que vous posez.