Provisionnement
Ouvrez l’onglet Base de données de votre projet et provisionnez. Vous obtenez une base et un rôle dédiés, et le DSN est injecté dans votre application comme DATABASE_URL au prochain déploiement. Les détails complets de connexion (hôte, port, utilisateur, mot de passe) restent visibles sur l’onglet pour vos outils externes. Les bases partagent le stockage groupé de votre organisation avec les sauvegardes, les objets et les jeux de données de l’Atelier de données (voir les limites) : une nouvelle base n’augmente jamais le total.
import pg from 'pg';
// DATABASE_URL is injected automatically once a database is provisioned.
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });
const { rows } = await pool.query('SELECT now()');Version de Postgres
Au moment de provisionner, choisissez Postgres 17 (par défaut) ou Postgres 18. L’onglet Base de données affiche la version exacte en exécution — par exemple, 17.9 — pas seulement la version majeure. Une base existante reste sur sa version de création; rien ne change à moins que vous ne le choisissiez.
Pour faire passer une base existante à une autre version, videz-la et restaurez-la dans une base fraîchement provisionnée (pg_dump depuis l’ancienne, pg_restore dans la nouvelle). Votre DATABASE_URL est réinjectée au prochain déploiement.
Migrations et amorçage
Exécutez vos migrations dans la commande de mise en production du projet (Paramètres → Compilation) — par exemple npx prisma migrate deploy ou drizzle-kit migrate. Elle s’exécute une fois par déploiement en production, après une compilation réussie et avant le démarrage de la nouvelle version, et jamais lors des déploiements d’aperçu. Évitez de lancer les migrations dans votre script de compilation : les compilations ont aussi lieu pour les déploiements d’aperçu, avec la même base de données.
Plusieurs bases de données par projet
Un projet peut contenir plus d’une base de données — pour un entrepôt de lecture, un second service dans le même dépôt, ou des données de préproduction séparées de la production. Ajoutez-en une depuis l’onglet Base de données ou avec canner db create <nom> : la première base reste DATABASE_URL, et chaque base supplémentaire est injectée sous DATABASE_URL_<NOM> (en majuscules) au prochain déploiement. Le forfait Démarrage inclut une base par projet; les forfaits payants peuvent en ajouter.
Exportation, importation et migration
Exportez une base depuis son onglet, ou avec canner db export — un pg_dump restaurable n’importe où avec pg_restore (ou du SQL compressé pour psql). L’exportation est offerte avec tous les forfaits.
L’importation restaure un fichier pg_dump au format personnalisé dans une base Canner (canner db import backup.dump), et la migration entrante transfère en continu une base depuis n’importe quel serveur Postgres accessible publiquement — Heroku, Supabase, RDS, un autre projet Canner — sans fichier local (canner db migrate-in --from <url>). Les deux exigent une base cible vide, sauf si vous choisissez de la remplacer, auquel cas Canner conserve d’abord un instantané du contenu précédent. Chaque restauration est atomique : en cas d’échec, la base reste exactement comme avant. La migration sortante envoie une base Canner vers un serveur que vous indiquez; la copie duplique une base Canner dans une autre. L’importation, la migration entrante et la migration sortante sont offertes avec tous les forfaits; la copie (et le bouton de clonage) exige un forfait payant.
Connexion de l’extérieur
Une base de projet est toujours joignable depuis l’intérieur de Canner — votre application, l’Atelier de données, les requêtes planifiées. Pour y connecter directement un client local, psql ou un outil de BI, activez l’accès externe depuis l’onglet de la base : il ouvre un point d’accès TLS uniquement, restreint aux adresses IP ou plages CIDR que vous autorisez, rien d’autre. Désactivez-le en tout temps pour refermer le point d’accès. La rotation du mot de passe est désactivée tant que l’accès externe est activé pour cette base (désactivez l’accès, faites la rotation, puis réactivez-le) afin que les connexions externes ne soient pas coupées en cours de rotation. Offert avec tous les forfaits.
Analytique sur vos données
Les bases de projet apparaissent comme source dans l’Atelier de données : parcourez les tables et exécutez du SQL depuis le tableau de bord. Pour lire ou écrire dans votre base selon une planification — cumuls nocturnes, rapprochements, transferts entre projets — utilisez les requêtes SQL planifiées.
Sauvegardes
La base de données propre à la plateforme Canner est sauvegardée chaque nuit, peu importe le forfait. Pour les bases de projet, activez une politique de sauvegarde depuis l’onglet de la base (ou canner db backup-policy <nom> --enable --every 24 --keep 7) : la fréquence (au minimum chaque heure) et la durée de conservation de chaque sauvegarde (au minimum un jour, avec un plafond facultatif sur le nombre conservé). Vous pouvez aussi lancer une sauvegarde à la demande en tout temps avec Sauvegarder maintenant (ou canner db backup <nom>). Chaque sauvegarde est chiffrée au repos avec sa propre clé — supprimer une sauvegarde détruit cette clé immédiatement, rendant le fichier irrécupérable avant même que l’espace disque ne soit libéré. Le forfait Démarrage peut sauvegarder une fois par jour (un intervalle planifié d’au moins 24 heures, et une sauvegarde par période de 24 heures, sauvegardes à la demande comprises); les forfaits payants peuvent planifier aussi souvent qu’aux heures.
La restauration se fait par défaut dans une toute nouvelle base (le forfait Démarrage, avec sa base par projet, restaure plutôt sur place ou examine d’abord), de sorte que rien d’existant n’est jamais touché par erreur; depuis le même panneau, vous pouvez plutôt restaurer directement dans une base existante, ce qui remplace son contenu après que Canner en ait pris un instantané (conservé 7 jours, comme pour une importation avec remplacement). Les sauvegardes comptent dans l’utilisation du stockage groupé de votre organisation, affiché sur l’onglet de la base, avec l’archive de récupération et le WAL retenu pour la réplication. Les sauvegardes sont les premières à s’arrêter : à 100 %, les nouvelles sauvegardes et les téléversements sont suspendus (les sauvegardes planifiées sont sautées et les plus anciennes réduites à la plus récente, plutôt que de laisser les sauvegardes elles-mêmes vous bloquer). Les écritures dans les bases ne sont verrouillées que lorsque le stockage dépasse sa limite de 10 %, et se déverrouillent sous 90 %.
Ce que contient une sauvegarde
Une sauvegarde couvre vos données, pas votre configuration. Elle comprend la base de données (schéma et données; avec l’identité de sauvegarde superutilisateur, aussi les privilèges, les politiques et une exportation des rôles) et vos fichiers téléversés avec leurs versions. Elle ne comprend pas les variables d’environnement, les clés de chiffrement ni les autres secrets, les domaines ou les réglages du projet.
Conservez votre propre copie des secrets. canner env --reveal --json les affiche; gardez le résultat dans un gestionnaire de secrets, jamais à côté de la sauvegarde. Une restauration sans la clé qui chiffre des identifiants contenus dans vos données (un jeton de fournisseur de paiement, par exemple) ne peut pas les déchiffrer.
Examiner une restauration d’abord
Choisissez Examiner d’abord lorsque vous restaurez une sauvegarde (ou récupérez à un instant précis) et Canner la restaure dans une base temporaire à examiner, avec sa propre chaîne de connexion. Elle n’est jamais injectée dans votre application et se supprime d’elle-même après 24 heures, sauf si vous la conservez ou la prolongez. Explorez-la avec n’importe quel client, ou utilisez Comparer avec la base actuelle pour voir les tables nouvelles, absentes ou différentes, avec le nombre de lignes. Quand vous êtes satisfait, conservez-la comme base et copiez-la par-dessus l’originale. Avec la CLI : canner db backups <nom> <id> --restore --inspect, canner db diff <base à examiner> et canner db inspect <base à examiner> --keep.
Alertes et sauvegardes vérifiées
Canner vous prévient quand quelque chose demande votre attention : une sauvegarde échoue, aucune sauvegarde n’a réussi depuis deux intervalles, l’archivage de la récupération à un instant précis échoue, votre stockage atteint 80 % ou 95 % ou est plein, ou une base à examiner est sur le point d’expirer. Chaque problème forme un seul incident : vous êtes prévenu une fois, puis relancé à intervalles espacés tant qu’il dure, et il se résout de lui-même. Les alertes sont envoyées par courriel à tous les administrateurs de l’organisation, ou aux adresses de votre choix, et au besoin à un webhook https signé avec X-Canner-Signature: sha256=<HMAC-SHA256 du corps>. Gérez-les depuis l’aperçu des bases ou avec canner db alerts.
Une sauvegarde que personne n’a restaurée n’est qu’un espoir : la nuit, Canner restaure donc votre sauvegarde la plus récente dans une base temporaire, relit chaque table, supprime cette base et marque la sauvegarde Vérifiée. Un essai raté déclenche une alerte. Vous pouvez aussi vérifier une sauvegarde à la demande (canner db backups <nom> <id> --verify) ou désactiver les essais de nuit dans les paramètres d’alertes.
Rôles pour analystes et services
L’identifiant propriétaire de votre base peut tout modifier : ne le distribuez pas. Créez plutôt des rôles nommés, chacun avec son mot de passe et sa chaîne de connexion. Un rôle en lecture seule peut lire toutes les tables (y compris celles créées plus tard) et rien d’autre; un rôle en lecture et écriture peut aussi insérer, modifier et supprimer. Aucun ne peut créer, modifier ou supprimer quoi que ce soit, ni atteindre une autre base. Les rôles sont une fonction de l’instance dédiée (un rôle peut lire toutes les tables de la base à laquelle il se connecte, ce qui n’est sûr que sur un serveur qui appartient à un seul client). Les rôles suivent la liste d’adresses autorisées de l’accès externe, suivent la base lorsqu’elle est déplacée ou change de version, et perdent l’écriture en même temps que le propriétaire si le verrouillage d’écriture du stockage s’enclenche. Jusqu’à 10 par base : canner db roles <nom> create bi --read-only. Changer le mot de passe d’un rôle, comme celui du propriétaire, exige de couper d’abord l’accès externe.
Les rôles que vous créez vous-même en SQL (le propriétaire de votre base le peut, sur l’instance dédiée) apparaissent dans la même liste, marqués comme créés en SQL. Un rôle de supervision a besoin de pg_monitor, que le propriétaire d’une base ne peut pas accorder : cochez-le sur le rôle ici (ou l’un de pg_read_all_stats, pg_read_all_settings, pg_stat_scan_tables) et nous l’accordons sur votre instance. Seuls ces quatre rôles sont offerts, jamais un rôle qui lit des données.
Copies de sauvegarde hors site
Les sauvegardes résident sur le serveur qui les a produites. Pour en garder une copie ailleurs, ajoutez une destination : un compartiment qui vous appartient chez n’importe quel service compatible S3 (Backblaze B2, Wasabi, Cloudflare R2, AWS S3, MinIO…). Vous pouvez en ajouter jusqu’à cinq (canner db offsite add …), chacune avec un nom, et appuyer sur Essayer pour chacune. Choisissez ensuite, pour chaque base, la destination de ses copies sous Copier les sauvegardes hors site vers(canner db backup-policy <nom> --offsite <destination>) : des bases différentes peuvent utiliser des compartiments différents. Retirer une destination arrête les copies vers elle et met fin au secours pour les sauvegardes qu’elle contenait. Chaque sauvegarde est copiée quelques minutes après sa fin, les plus récentes d’abord. Ce qui arrive dans votre compartiment est déjà chiffré avec la clé propre à cette sauvegarde, qui reste chez Canner : le compartiment seul est illisible, et supprimer une sauvegarde (y compris par la rétention) supprime sa copie et la rend définitivement illisible, même si la suppression distante doit être reprise. Si le fichier local est un jour perdu, les restaurations et téléchargements se rabattent sur la copie. Vous recevez une alerte si la copie échoue de façon répétée.
Mémoire pour votre application et votre base
Votre application et son instance Postgres dédiée partagent un seul budget de mémoire. Une partie est partagée : l’allocation de votre forfait, utilisée avec souplesse et ralentie (jamais arrêtée par surprise) quand le serveur est occupé. Une partie est garantie : 0,5 Go accompagne l’instance dédiée, et vous pouvez ajouter de la RAM dédiée par blocs de 1 Go (19 $ par mois chacun) que personne d’autre ne peut prendre. Si vous voulez seulement plus de mémoire pour votre application, la RAM d’application (4 $ le Go par mois) s’ajoute plutôt à la partie partagée; voir RAM d’application ou RAM dédiée ? pour choisir. L’aperçu des bases montre la répartition : par défaut, Postgres prend la moitié de la mémoire partagée et toute la mémoire garantie; vous pouvez déplacer le curseur ou garder la RAM achetée pour votre application (canner db resources set --share 40). Appliquer dimensionne Postgres pour sa part (tampons partagés, cache et limites de connexions) et impose une limite de mémoire stricte à l’instance : une requête incontrôlée est arrêtée à l’intérieur de votre instance et n’affecte jamais les autres clients; l’application redémarre l’instance quelques secondes. La limite de mémoire de votre application est abaissée à sa part du budget et prend effet à son prochain déploiement. La RAM garantie est limitée à une part de chaque serveur : un achat peut donc être refusé quand tout est vendu.
Extensions
Sur l’instance dédiée, chaque base a une liste d’extensions : pgvector (vector), PostGIS, pg_trgm, unaccent, citext, hstore, pgcrypto, uuid-ossp, btree_gin, btree_gist, fuzzystrmatch, ltree, tablefunc et pg_cron(canner db extensions <nom> install vector). Elles s’installent immédiatement et fonctionnent avec vos propres rôles de base de données. La liste est fixe volontairement : les extensions qui peuvent joindre d’autres serveurs ou lire les fichiers de l’hôte (postgres_fdw, dblink, file_fdw) ne sont pas offertes. Une extension installée peut être mise à jour vers la version actuelle du serveur et retirée; le retrait est refusé tant que des colonnes, des index ou des fonctions l’utilisent, afin de ne rien perdre par accident. pg_cron charge une bibliothèque au démarrage de Postgres : son installation redémarre l’instance, maintenant ou pendant votre fenêtre de maintenance, et elle s’exécute dans une seule base de l’instance. Ses tâches s’exécutent avec le rôle qui les a planifiées.
Réglages et fenêtre de maintenance
Choisissez un préréglage de charge (équilibré, lectures intensives, écritures intensives ou analytique) et les délais d’expiration voulus : requêtes, transactions inactives et attente de verrous (canner db tuning --preset write-heavy --statement-timeout 30). Ils prennent effet immédiatement, sans redémarrage, dans des limites sûres; le dimensionnement de la mémoire vient toujours de votre budget de mémoire. La fenêtre de maintenance dure deux heures, le jour et dans le fuseau horaire de votre choix : c’est là que se font les redémarrages planifiés. Tout ce qui exige un redémarrage (installer pg_cron, activer la réplication logique) peut se faire maintenant ou attendre la fenêtre, et canner db restart --yes le fait tout de suite.
Réplication logique
Activez la réplication logique pour diffuser les changements d’une base vers un autre Postgres : une réplique que vous gérez, un entrepôt de données, une autre région (canner db replication <nom> on --yes; l’instance redémarre). Créez une publication pour les tables voulues et un accès de type réplication (canner db roles <nom> create feed --replication) pour le destinataire. Il se connecte par la même adresse et la même liste d’adresses autorisées que l’accès externe, qui doit être activé pour la base; cet accès peut lire la base et ouvrir des connexions de réplication, rien d’autre : il ne peut ni écrire, ni créer d’objets, ni atteindre vos autres bases, ni ouvrir une copie de tout le serveur.
Un destinataire qui cesse de lire ferait conserver du WAL par Postgres jusqu’à remplir le disque : il y a donc une limite, la quantité maximale de WAL qu’un slot peut retenir (2 Go par défaut, réglable avec canner db replication <nom> cap 4096). Au-delà, Postgres invalide le slot et le destinataire doit être reconfiguré. Gardez la limite supérieure à votre plus grosse transaction. Chaque slot indique ce qu’il retient et son état de santé, le WAL retenu compte dans votre stockage, et vous recevez une alerte quand un slot prend du retard, reste inactif une journée ou est invalidé.
Suivre un serveur externe
Dans l’autre sens : une base de votre instance dédiée peut recevoir en direct les changements d’un autre serveur Postgres, pour migrer sans interruption ou garder une copie d’un autre système (canner db subscriptions <nom> add ancien --from-env SRC_URL --publication app_pub). Créez d’abord ici les tables avec les mêmes noms et colonnes (restaurez le schéma), et une publication sur l’autre serveur; donnez ensuite à Canner l’URL de connexion d’un utilisateur autorisé à répliquer. Les lignes existantes sont copiées d’abord, puis les changements arrivent en continu; la base indique combien de tables sont à jour et quand le dernier changement est arrivé, et vous pouvez actualiser (après avoir ajouté des tables à la publication), suspendre, reprendre ou arrêter. Jusqu’à cinq abonnements par base.
L’autre serveur doit être joignable depuis Internet à une adresse publique (les adresses privées, de bouclage et de métadonnées infonuagiques sont refusées), et la connexion est chiffrée sauf si vous indiquez autrement avec sslmode. Le mot de passe est saisi dans un champ masqué et remis à Postgres; Canner ne le conserve pas. Les changements sont appliqués avec les droits du propriétaire de vos tables, jamais en superutilisateur : un déclencheur sur vos tables s’exécute donc avec vos seuls droits. Deux choses à savoir : les changements répliqués s’exécutent avec un search_path vide, donc les fonctions de déclencheur doivent écrire des noms qualifiés par le schéma (public.audit, pas audit); et si un changement ne peut pas être appliqué (table manquante, ligne en conflit), l’abonnement affiche En échec, vous recevez une alerte, et il réessaie de lui-même une fois la cause corrigée. L’arrêt supprime le slot sur l’autre serveur; si ce serveur n’existe plus, utilisez --force.
Les sauvegardes s’exécutent en tant que
Sur une instance dédiée, Canner lit vos bases pour les sauvegardes, les exportations et les copies soit en tant que propriétaire de la base (par défaut), soit en tant que superutilisateur de l’instance. Le choix se fait sous Sauvegardes, Les sauvegardes s’exécutent en tant que. Seuls les administrateurs de l’organisation peuvent le modifier, le changement est consigné dans le journal d’audit, et passer à superutilisateur lance une nouvelle sauvegarde de chaque base pour que vous voyiez le résultat tout de suite.
Choisissez le superutilisateur quand le propriétaire ne voit pas toutes ses données. Une table dont la sécurité au niveau des lignes est forcée (FORCE ROW LEVEL SECURITY) applique ses politiques même à son propriétaire : une sauvegarde exécutée par le propriétaire s’arrête alors avec une erreur de sécurité au niveau des lignes. Le superutilisateur lit toutes les lignes et ne dépend pas du mot de passe du propriétaire; le changer en SQL ne brise donc jamais une sauvegarde.
Une sauvegarde exécutée en superutilisateur conserve ce qu’il faut à une restauration fidèle en plus des données : les privilèges et les privilèges par défaut, ainsi que les rôles utilisés par la base (groupes, connexions, appartenances, réglages et privilèges au niveau de la base), avec les empreintes de mot de passe, stockés chiffrés avec la sauvegarde. La restaurer dans Canner remet les données avec les mêmes permissions, sans que vous ayez à fournir un fichier ni des identifiants : les rôles que votre serveur n’a plus sont recréés, et ceux qui existent gardent leur mot de passe actuel. La sécurité au niveau des lignes, les politiques et le RLS forcé reviennent tels quels, et la restauration d’essai de vérification contrôle que chaque table qui contenait des lignes en contient toujours. Une restauration à un instant précis sur une telle instance fait de même. Deux choses à savoir : une sauvegarde prise en superutilisateur ne peut être restaurée que sur l’instance dédiée d’où elle vient (et par-dessus une base seulement tant que Les sauvegardes s’exécutent en tant que est encore réglé sur superutilisateur), et une copie restaurée dont le propriétaire est différent ne reçoit pas les privilèges par défaut du propriétaire d’origine. Remplacer la base en service par une copie restaurée avec canner db copyconserve aussi les permissions, et la base en service garde ses propres privilèges par défaut.
Pour restaurer une sauvegarde téléchargée sur votre propre serveur, téléchargez la sauvegarde et son fichier Rôles (.sql), exécutez psql -v dbname=mabase -f roles.sql en superutilisateur, puis pg_restore --no-owner --dbname mabase sauvegarde.dump. Le fichier de rôles contient des empreintes de mot de passe : seuls les administrateurs de l’organisation peuvent le télécharger. Les sauvegardes prises en tant que propriétaire n’ont pas de fichier de rôles.
Chaque sauvegarde enregistre aussi son schéma et ses politiques : un fichier JSON qui liste les tables et les colonnes, les index, les contraintes, les fonctions, l’état de la sécurité au niveau des lignes de chaque table, les politiques, les privilèges (y compris par colonne et par défaut) et les rôles concernés, avec le nombre de lignes relevé au moment de la sauvegarde et deux empreintes (une pour la structure, une pour les permissions). Il ne contient ni données ni empreintes de mot de passe; on peut donc le joindre à un billet ou à un dossier d’audit. Téléchargez-le avec Schéma et politiques à côté de la sauvegarde, ou par l’API avec ?compare=live pour qu’il indique aussi en quoi la base en service diffère maintenant. Une restauration d’essai de vérification compare la copie restaurée à cet enregistrement et échoue si une table, une colonne, une politique ou un privilège n’est pas revenu. Les sauvegardes antérieures n’ont pas ce fichier; faites une nouvelle sauvegarde.
Archive de récupération chiffrée
La récupération à un instant précis conserve deux choses sur le serveur : une sauvegarde de base périodique et le flux de WAL entre elles. Les deux sont compressés et chiffrés avec AES-256 (authentifié) avant d’être écrits, avec une clé propre à votre instance et conservée scellée dans la base de contrôle de Canner. Supprimer l’instance supprime la clé, ce qui rend toute copie restante illisible. Cela protège les fichiers de l’archive eux-mêmes (une copie du dossier d’archive, un instantané, une copie expédiée); ce n’est pas un chiffrement de disque de tout le serveur. Les instances qui archivaient avant cette fonction passent automatiquement aux fichiers chiffrés, et leurs anciens fichiers restent restaurables.
Pour survivre à la perte du serveur lui-même, envoyez une seconde copie hors site : sous la récupération à un instant précis, choisissez une destination (l’un de vos seaux hors site, voir plus haut) pour Copier l’archive de récupération hors site(canner db pitr --offsite <destination>). Le nouveau WAL et les sauvegardes de base sont téléversés en quelques minutes, déjà chiffrés, et la copie suit votre fenêtre de conservation : ce que la fenêtre supprime localement est aussi supprimé du seau. Si des fichiers manquent un jour sur le serveur, une restauration les récupère d’abord depuis le seau. Choisir une autre destination repart de zéro; désactiver la récupération à un instant précis ou supprimer l’instance supprime la copie. Comme pour les sauvegardes hors site, la clé reste chez Canner : le seau seul ne peut pas être lu. L’archive doit être chiffrée, et les fichiers expédiés comptent dans votre propre seau, pas dans le stockage groupé de Canner.
Métriques, requêtes lentes et journaux
Chaque base affiche ses métriques : connexions, transactions, taux d’accès au cache et taille sur la dernière heure, le dernier jour, la dernière semaine ou 30 jours (canner db metrics <nom>). Une base sur l’instance dédiée montre aussi la mémoire et le processeur de l’instance. Les métriques sont échantillonnées toutes les quelques minutes : une base toute neuve commence donc vide.
Sur l’instance dédiée, vous pouvez activer les requêtes lentes et les journaux(canner db monitoring on --yes). Cela active pg_stat_statements et le collecteur de journaux Postgres et redémarre l’instance quelques secondes : c’est donc à vous de décider. Vous obtenez ensuite vos requêtes les plus lentes et les plus fréquentes (constantes remplacées par $1, $2…), triées par temps total, moyenne, nombre d’appels ou exécution la plus lente, et un journal consultable des erreurs, avertissements et requêtes plus lentes qu’un seuil que vous fixez (500 ms par défaut), conservé sept jours. Les deux sont limités à la base que vous consultez, jamais aux autres. Les lignes du journal contiennent le texte des requêtes lentes ou en échec, y compris les valeurs littérales. La désactivation supprime les deux et redémarre de nouveau l’instance.
Instance dédiée et récupération à un instant précis
Pour une base qui a besoin de son propre serveur, un projet peut avoir une instance Postgres dédiée : un vrai processus Postgres distinct, avec son propre répertoire de données et sans plafond de mémoire, qui contient une partie ou la totalité des bases du projet. Choisissez la version de Postgres à la création (elle est fixe pour l’instance), puis ajoutez-y des bases avec canner db create <nom> --instance, ou déplacez-y une base existante avec canner db move <nom> --to instance. Un déplacement est un vidage puis une restauration, avec une véritable interruption pendant son exécution; la chaîne de connexion ne change pas et, en cas d’échec, la base reste exactement comme avant. Vous pouvez ramener une base vers l’hébergement partagé de la même façon. C’est une option payante, facturée par projet.
Chaque projet a besoin de sa propre unité (9 $ par mois). Pour en obtenir une, cochez Instance dédiée à la création de la première base du projet, utilisez le bouton Passer d’une base existante, ou lancez canner db init --dedicated. Si aucune unité n’est encore attribuée au projet, une est ajoutée à votre forfait : le tableau de bord et la CLI affichent le prix et demandent d’abord une confirmation (la CLI exige --yes), et rien n’est facturé avant. canner billing addons liste les unités que vous possédez et où elles sont attribuées, et canner billing preview dedicated_instance 3 montre ce que coûterait la possession de trois unités, sans rien acheter.
Une instance peut aussi offrir la récupération à un instant précis, activée ou non à la création et modifiable par la suite. Lorsqu’elle est activée, Canner archive chaque changement et prend une sauvegarde de base selon un horaire; vous choisissez la fenêtre (de 1 à 35 jours, 7 par défaut). Pour récupérer, choisissez un moment dans la fenêtre (ou « le plus récent ») et Canner recrée cette base telle qu’elle était alors, sous forme de toute nouvelle base — rien d’existant n’est touché (canner db pitr-restore <nom> --to 2026-09-23T14:00:00Z). Pour la mettre à la place de l’originale, copiez-la par-dessus avec canner db copy <restaurée> <nom> --replace, ce qui prend d’abord un instantané de l’existant. Le tableau de bord affiche la plage récupérable et l’état de l’archive. Désactiver la récupération à un instant précis supprime définitivement l’archive.
L’archive de récupération compte dans le stockage groupé de votre organisation, comme les sauvegardes. Si l’option n’est plus active, l’instance est arrêtée et ses données sont conservées; rien n’est supprimé automatiquement. Vous pouvez toujours en déplacer les bases ou les exporter. L’archive de récupération se trouve sur le même serveur que l’instance : elle vous protège des erreurs (une mauvaise migration, une suppression accidentelle), pas de la perte du serveur lui-même — sauf si vous la copiez aussi hors site (voir plus haut); les copies nocturnes hors serveur de Canner couvrent le reste.