Point-in-time recovery Supabase : prix et limites

Vous êtes sur le plan Pro de Supabase, quelque chose a mal tourné à une heure que vous pourriez noter, et la sauvegarde de cette nuit est plus vieille que l'erreur. Quelque part dans le tableau de bord se trouve un interrupteur appelé Point in Time Recovery avec un prix à côté, et la question est de savoir si ce prix achète ce que vous croyez.

Voici la partie que chaque comparatif aplatit : le point-in-time recovery et une copie que vous détenez sont deux produits différents, et activer le premier ne change rien à ce pour quoi le second existe. Les deux figurent sous Backups dans le tableau de bord, et c'est là que naît l'essentiel de la confusion.

Il aide de voir l'un comme un enregistrement et l'autre comme une photographie. Une sauvegarde quotidienne est une photographie : une image par jour, prise à heure fixe, et vous pouvez la sortir du bâtiment. Le point-in-time recovery est la caméra du bâtiment lui-même, qui tourne en continu et vous laisse vous arrêter sur l'image que vous voulez. Les bandes sont au sous-sol et remontent sur une semaine.

Qu'est-ce que le point-in-time recovery chez Supabase ?

C'est une manière de ramener votre base de données à un instant précis plutôt qu'à une sauvegarde précise.

Supabase le construit avec deux choses qui fonctionnent ensemble. La première est une sauvegarde physique, un instantané quotidien des fichiers de la base. La seconde est l'archivage du Write Ahead Log : Postgres tient un registre continu de chaque modification qu'il effectue, et Supabase emporte ces fichiers toutes les deux minutes, ou immédiatement dès que l'un dépasse une certaine taille. Une restauration charge l'instantané puis rejoue le journal en avant jusqu'à atteindre l'instant demandé.

C'est de ce mécanisme que vient la précision. Supabase décrit le résultat comme une granularité allant jusqu'à la seconde, avec un pire cas qu'ils chiffrent à un Recovery Point Objective de deux minutes, autrement dit le maximum que vous pourriez perdre au bout de l'instant choisi.

Leur documentation des sauvegardes est la page où figure la forme actuelle de tout cela. Tout ce qui suit ici dépend de chiffres qui leur appartiennent.

Combien coûte le point-in-time recovery de Supabase ?

$100 par mois pour une fenêtre de sept jours, en plus du plan Pro, qui coûte à lui seul $25 par mois.

Supabase facture l'option à l'heure et vend trois tailles de fenêtre :

Il y a une seconde ligne sur la facture, et c'est celle qui surprend. Le point-in-time recovery exige au minimum l'instance de calcul Small. Un projet Pro tourne par défaut sur Micro, que les $10 de crédit de calcul inclus dans le plan couvrent entièrement ; Small se situe autour de $15 par mois, le crédit cesse donc de couvrir votre calcul et le reste commence à apparaître sur votre facture. L'option revient de ce fait un peu plus cher que le chiffre imprimé à côté d'elle.

Elle est disponible sur Pro, Team et Enterprise. Sur le plan gratuit il n'y a rien à quoi l'ajouter, puisque le plan gratuit ne prend aucune sauvegarde automatique.

Vérifiez les deux chiffres sur la page de tarifs de Supabase le jour où vous décidez, et pas sur celle-ci. Ils leur appartiennent, et cette page ne s'en apercevra pas quand ils changeront.

Quand le point-in-time recovery vaut-il son prix ?

Quand vous pouvez nommer la minute, et quand le travail de part et d'autre compte.

Une migration a tourné à 14:32 et a emporté une colonne. Un script lancé à midi a écrit la mauvaise valeur dans chaque ligne. Un agent IA a reçu un accès en écriture et s'en est servi. Dans les trois cas vous savez quand, et ce quand est toute l'entrée. Vous choisissez 14:31, et la base revient telle qu'elle était une minute avant les dégâts.

Ce qui coûte de l'argent, c'est le reste de cette matinée. Restaurer la copie de minuit efface aussi chaque inscription, chaque commande et chaque message créés par vos utilisateurs depuis minuit, si bien qu'annuler une erreur revient à accepter une seconde perte, plus petite. Avec le point-in-time recovery, le travail de la matinée reste.

Pendant que vous êtes dans le tableau de bord à penser à ce qui pourrait mal tourner, il vaut la peine de savoir ce que votre application montre déjà à un inconnu. Notre scan gratuit lit votre site en ligne depuis l'extérieur et vous dit ce qu'il voit. Il prend une vingtaine de secondes et ne demande aucun compte : scannez votre application.

Ce que le point-in-time recovery n'atteint pas

Deux choses : une erreur repérée après le passage de la fenêtre, et le compte dans lequel tout le dispositif se trouve.

Une erreur repérée tard. La fenêtre avance avec la journée d'aujourd'hui, une fenêtre de sept jours est donc toujours les sept derniers jours et jamais une semaine fixe. Pour une suppression c'est généreux, parce qu'une suppression se signale en général en quelques minutes. Pour la variété silencieuse elle n'aide pas du tout : un formulaire qui enregistre la mauvaise valeur depuis mardi en quinze, une colonne disparue dans une migration que personne n'a lue de près, un champ qu'un script écrase depuis un mois. Ces choses-là ressortent quand un client écrit, et un client qui écrit le fait rarement dans les sept jours suivant la cause.

Le compte où vit la récupération. Les instantanés et le journal archivé se trouvent dans votre projet Supabase, et c'est précisément ce qui les rend rapides et les réduit à un clic. Cela veut dire aussi qu'un projet suspendu, une carte expirée ou un accès que vous ne récupérez pas emportent la récupération avec ce qu'elle protégeait. C'est un échange honnête et non un défaut, et c'est la raison pour laquelle une copie dans votre compte n'est que la moitié d'un filet.

Le point-in-time recovery couvre-t-il mes fichiers Storage ?

Non. Les mots de Supabase sont que les sauvegardes de base de données n'incluent pas les objets stockés via la Storage API, et le point-in-time recovery est une fonction de la base.

Chaque avatar, chaque PDF envoyé et chaque photo de produit ajoutée par vos utilisateurs vit dans Storage, qui est un service séparé. Votre base garde le chemin de chaque fichier et rien de son contenu. Une base rembobinée à mardi pointe donc vers ce qui se trouve aujourd'hui dans vos buckets, et un fichier supprimé mercredi reste supprimé après une récupération parfaitement réussie.

Quoi que vous décidiez sur cette page, vos fichiers demandent leur propre réponse. Trois façons de sauvegarder une base Supabase raconte où chaque voie les laisse.

Un outil tiers peut-il me donner du point-in-time recovery ?

Non, et c'est l'affirmation du sujet qui mérite le plus d'être regardée de près, parce qu'elle sonne comme une comparaison de fonctions et qu'elle est une différence de catégorie.

Le point-in-time recovery rejoue le write-ahead log, et ce journal est un fichier sur le disque où tourne votre base. Le lire suppose de se tenir sur cette machine. Tout outil de sauvegarde extérieur, le nôtre compris, se connecte à votre base comme le fait votre application, lui demande son contenu et note la réponse. Ce qui en sort est un dump logique : une copie complète et transportable de tout ce que contenait la base au moment où il a tourné.

Un dump, c'est de nouveau la photographie. Vous pouvez l'emporter n'importe où, le charger dans un projet tout neuf sur un autre compte et le lire avec des outils Postgres ordinaires qui n'ont jamais entendu parler de Supabase. Ce que vous ne pouvez pas faire, c'est vous arrêter entre deux dumps, parce qu'entre les deux rien n'enregistrait.

Voici donc la version honnête de la comparaison. Si ce qu'il vous faut est de retomber sur 14:31, achetez l'option de Supabase ; personne en dehors de la plateforme n'est en mesure de vous la vendre. Un fournisseur qui annonce du point-in-time recovery par-dessus une connexion décrit un calendrier, et une question sépare les deux : sa restauration retombe-t-elle sur une minute que vous tapez, ou sur le dernier passage de sa copie ?

Point-in-time recovery, ou une copie que vous détenez ?

Demandez-vous contre quel désastre vous vous assurez, car ces deux-là répondent à des désastres différents.

La plupart des applications avec de vrais clients veulent les deux, et c'est l'ordre qu'il faut décider en conscience. La copie que vous détenez est celle qui survit à tout, y compris au compte, c'est donc la première à mettre en place. L'option, on l'achète une fois qu'on a calculé que perdre une matinée de commandes coûte plus cher qu'elle.

Que faire cette semaine

Où Reeve Care s'inscrit

Care est la copie que vous détenez, mise en place pour vous, avec une restauration que vous pressez au lieu de l'assembler.

• Les copies tournent selon un calendrier que vous n'avez pas à retenir, toutes les six heures sur les plans supérieurs, et un passage qui échoue vous envoie un e-mail plutôt qu'un silence.
• Chaque copie vit hors de votre compte Supabase. Chiffrée, sur un stockage que nous détenons, pour qu'un projet suspendu ou un accès perdu n'emporte pas vos sauvegardes avec lui.
• Chaque copie est relue avant de compter. La date affichée dans votre tableau de bord est celle de la dernière copie qui a passé ce contrôle, jamais de la dernière tentative.
• Restaurer est un bouton, et il prend un instantané de l'état actuel avant de commencer, si bien que la restauration a elle aussi son annulation.
• Les fichiers envoyés par vos utilisateurs sont copiés eux aussi, dès que vous connectez vos buckets Storage. C'est une seconde clé, demandée à part, parce que la clé que Supabase délivre pour Storage sait écrire en plus de lire et que nous préférons demander plutôt que la mêler à une clé qui ne le peut pas.

Care et l'option se complètent, et c'est aussi ainsi qu'ils sont tarifés. Care démarre à €49 par mois pour une application, face à $100 pour l'option, et beaucoup d'applications devraient avoir le premier avant d'envisager la seconde. Les nôtres sont des prix de liste, et la page des tarifs se situe parfois sous le chiffre indiqué ici et jamais au-dessus. Chaque chiffre de Supabase sur cette page est cité depuis leurs propres pages, sans conversion et sans estimation.

Comment une copie est prise, vérifiée et remise est dessiné étape par étape sur la page des sauvegardes Supabase.

Avant de fermer cet onglet, calculez le nombre dont dépend toute cette décision : combien de temps une erreur pourrait rester dans votre application avant que quelqu'un la remarque. En dessous de sept jours, l'option vous achète une vraie précision le jour où vous en avez besoin. Au-dessus, une fenêtre plus large n'est pas le bon endroit pour l'argent, car ce qui remonte plus loin est une copie à vous. La liste de sécurité en 10 minutes couvre les sauvegardes à côté du reste de ce qu'il vaut la peine de vérifier sur une application lancée.