Migrer PostgreSQL en local vers une base de données gérée

Migrer une base ne consiste pas à copier quelques lignes. Le serveur cible doit accepter le schéma et les extensions utilisés, l’application doit y accéder par un chemin réseau sûr et il faut une procédure de retour testée si les vérifications échouent. Ce guide décrit le transfert d’une base PostgreSQL depuis votre ordinateur ou un serveur que vous administrez vers un service géré. Il ne traite ni de la modification des modèles Prisma ni de l’application d’une migration de schéma : consultez le guide Prisma pour la production pour cette opération.

Choisir qui exploite le serveur PostgreSQL

Une base gérée vous évite d’installer et de mettre à jour PostgreSQL, d’administrer le système hôte et d’organiser ses tâches récurrentes. Un VPS vous donne plus de contrôle sur le système, les réglages et les extensions, mais vous confie aussi les correctifs, les accès, la supervision, les sauvegardes et les essais de restauration. Hostbrid propose des bases de données gérées et des VPS Cloud ; cela ne signifie pas que chaque charge ou extension est compatible avec les deux offres.

La page publique Hostbrid présente PostgreSQL, MariaDB et Redis. Elle mentionne les sauvegardes quotidiennes et, sur l’offre DB-HA, trois réplicas PostgreSQL avec bascule automatique. Elle précise aussi qu’une base n’a pas d’adresse IP publique par défaut et qu’elle est accessible depuis les services compatibles du compte ; un accès depuis l’extérieur demande une autorisation d’adresse IP. Consultez les caractéristiques et limites à jour avant de créer votre cible. Une sauvegarde quotidienne est utile, mais ne valide pas votre propre restauration et ne garantit pas que l’application acceptera un changement d’hôte sans adaptation.

Gardez PostgreSQL sur votre VPS si vous avez besoin du rôle superutilisateur, d’extensions ou de réglages qui ne sont pas exposés par l’offre gérée, ou d’un mode de déploiement non pris en charge. Choisissez le service géré seulement après avoir vérifié la version majeure, les extensions disponibles, le stockage, les limites de connexions et le chemin réseau autorisé. La page produit décrit l’offre en cours ; la documentation PostgreSQL fait autorité pour les outils de dump et de restauration.

Faire l’inventaire avant l’export

Notez la version majeure de PostgreSQL sur la source, la taille de la base, l’encodage, la collation, les extensions installées et les rôles utilisés par l’application. Listez les extensions depuis la source avec cette requête :

SELECT extname, extversion FROM pg_extension ORDER BY extname;

Vérifiez que chaque extension nécessaire est disponible sur la cible. Repérez les propriétaires, les droits, les politiques de sécurité par ligne, les séquences, les gros objets et les tâches planifiées. pg_dump exporte une base ; il ne comprend pas automatiquement tous les rôles du cluster ni chaque réglage serveur. Si l’application en dépend, créez une équivalence explicite sur la cible au lieu de restaurer aveuglément l’ancien cluster. Ne transférez que les données que vous avez le droit de déplacer et, si possible, commencez par un jeu anonymisé.

Créez la base cible et vérifiez son accès avant la restauration. Sur Hostbrid, récupérez dans le panneau l’hôte, le port, le nom de base, l’utilisateur et les paramètres TLS. Le service n’accepte pas par défaut des connexions publiques arbitraires. Lancez la migration depuis une ressource autorisée à joindre la base ou demandez l’accès temporaire le plus restreint possible depuis une adresse de confiance. N’ouvrez pas PostgreSQL à tout Internet. Retirez cette autorisation temporaire après le transfert.

Utilisez un client PostgreSQL capable de lire la version du serveur source et compatible avec la cible. La référence officielle de pg_dump explique la compatibilité : un dump est prévu pour être chargé sur des versions plus récentes, mais un client d’une version majeure plus récente n’est pas un choix sûr pour restaurer sur un serveur plus ancien. Vérifiez précisément la combinaison au lieu de supposer qu’un changement de version est transparent.

Créer une archive protégée et restaurer sur une cible vide

Stockez les accès source et cible dans un fichier de mots de passe libpq aux permissions restreintes ou dans un gestionnaire de secrets. Ne mettez pas les mots de passe dans l’historique du terminal, les journaux ou Git. Si vous utilisez .pgpass, réservez les droits au propriétaire (0600). Suivez le mode TLS et les contrôles de certificat fournis par le service cible ; ne désactivez pas la vérification pour contourner une erreur.

Après avoir rendu l’hôte, le port, la base et l’utilisateur source accessibles au client, créez une archive au format personnalisé :

pg_dump --format=custom --host="$SOURCE_HOST" --port="$SOURCE_PORT" \
  --username="$SOURCE_USER" \
  --dbname="$SOURCE_DB" --file=before-migration.dump
pg_restore --list before-migration.dump

pg_dump se connecte à une base et produit une exportation logique cohérente, même si le serveur reste en service. Le format personnalisé permet d’inspecter l’archive et de restaurer certains objets. Ici, --no-owner --no-acl à la restauration évite de reprendre les propriétaires et droits de l’ancien serveur ; les objets appartiendront au compte cible. Les autorisations changent donc : vérifiez le rôle de l’application et ses droits. Si vous devez conserver les rôles du cluster ou les propriétaires, définissez cette partie avec l’administrateur de base.

Créez sur la cible une base vide avec les extensions nécessaires, puis restaurez l’archive :

pg_restore --exit-on-error --no-owner --no-acl \
  --host="$TARGET_HOST" --port="$TARGET_PORT" --username="$TARGET_USER" \
  --dbname="$TARGET_DB" before-migration.dump

N’ajoutez pas --clean à une restauration de production pour faire disparaître des erreurs : cette option peut supprimer des objets. Restaurez d’abord dans une base vide et arrêtez-vous si pg_restore signale une erreur. La référence officielle de pg_restore détaille les options d’archive et le traitement des échecs. Conservez le dump chiffré dans un emplacement protégé jusqu’à validation, puis appliquez votre politique de conservation et de suppression.

Vérifier les données avant de changer l’application

Comparez la liste des tables et le nombre approximatif de lignes des tables importantes. Contrôlez les contraintes, index, séquences, droits, fuseaux horaires et quelques valeurs avec accents ou données binaires. Dans un environnement de test, connectez l’application à la cible et vérifiez l’authentification, les écritures, les tâches de fond et les références aux fichiers. Le dump ne transfère pas les fichiers téléversés, le stockage objet, le contenu du cache Redis, les courriels, les variables d’environnement ni les intégrations externes.

Pour une base de développement sans écriture de production, une seule exportation peut suffire. Pour un service actif, prévoyez une fenêtre de maintenance : passez l’application en lecture seule ou en maintenance, arrêtez les tâches et tous les processus d’écriture, faites un dump final, restaurez-le, puis modifiez l’unique DATABASE_URL ou secret équivalent. Cette bascule planifiée ne promet pas zéro interruption. Effectuez un test fonctionnel avant de réautoriser les écritures. Ne laissez pas les deux bases accepter des écritures sans réplication et stratégie de résolution des conflits testées.

Gardez la source intacte et en lecture seule jusqu’à ce que la nouvelle version ait passé les vérifications. En cas de retour arrière après de nouvelles écritures sur la cible, ces données ne seront pas sur la source. Décidez avant la bascule si vous acceptez une courte perte, rejouez les modifications ou maintenez le service en maintenance le temps de rapprocher les données. Une sauvegarde n’est réellement vérifiée qu’après un essai de restauration.

Après la bascule, surveillez les erreurs de connexion ainsi que l’espace et le nombre de connexions. Changez les identifiants si l’archive ou un accès temporaire a pu fuiter. Les changements de schéma ultérieurs sont une autre opération : consultez le guide des migrations Prisma. Si l’offre gérée répond à vos besoins d’extensions et de réseau, comparez les bases de données Hostbrid. Si vous devez exploiter vous-même le serveur, consultez les offres VPS. En cas de doute sur une compatibilité, posez la question avant de déplacer les données de production.