Vérifier les extensions PostgreSQL avant de choisir DigitalOcean Advanced Edition

PostgreSQL Advanced Edition de DigitalOcean est devenu une cible de migration plus plausible le 6 octobre 2026. Vous pouvez désormais activer 20 extensions supplémentaires, dont pg_trgm, citext et pgcrypto. Cela lève un obstacle pour certaines applications. La compatibilité de toutes les bases Standard Edition n’est toutefois pas acquise.

Commencez par inventorier les extensions et préciser vos besoins de restauration. Si l’un des contrôles ci-dessous échoue, conservez la base actuelle pendant que vous résolvez le problème. Ce guide sert à valider la compatibilité avant de préparer une bascule en production.

Transparence : le lien affilié DigitalOcean ci-dessous peut me rapporter une commission sans frais supplémentaires pour vous. Sources vérifiées le 7 octobre 2026. Ce guide repose sur la documentation ; je n’ai créé aucun cluster payant, exécuté ces exemples sur DigitalOcean ni mesuré le basculement pour cet article.

Ce qui a changé, et à quelle date

Advanced Edition est disponible généralement depuis le 17 septembre. Une note du 30 septembre indiquait que CREATE EXTENSION ne permettait plus d’ajouter des extensions. Celle du 6 octobre remplace cette restriction pour 20 extensions nommées. Les cinq extensions préinstallées restent disponibles. Il s’agit donc d’une évolution d’un produit déjà lancé. Notes de version DigitalOcean

La question utile concerne les dépendances de votre application. Un ancien comparatif, une réponse d’assistance de la semaine dernière ou la liste Standard Edition peuvent induire en erreur. Consultez le tableau Advanced actuel pour la version majeure de PostgreSQL envisagée.

Inventorier avant de choisir un forfait

Avec votre connexion habituelle autorisée, exécutez ces requêtes en lecture seule dans chaque base applicative source. Les extensions sont installées par base ; examiner uniquement defaultdb peut masquer une dépendance importante.

SELECT current_database(), current_user;
SHOW server_version;
SELECT e.extname, e.extversion, n.nspname AS object_schema
FROM pg_extension AS e
JOIN pg_namespace AS n ON n.oid = e.extnamespace
ORDER BY e.extname;

Conservez le résultat dans vos notes de migration. pg_extension recense les extensions installées et leur version. Inspectez aussi les migrations applicatives et les tâches planifiées pour repérer des dépendances attendues mais absentes de cet environnement. Catalogue des extensions PostgreSQL

Comparez chaque nom à la liste autorisée pour Advanced Edition. À la date de vérification :

Cette mise à jour n’autorise pas l’installation de n’importe quelle extension. Un nom dans le catalogue générique PostgreSQL ne remplace pas la liste du fournisseur. Ne supprimez pas une extension de production pour donner l’impression que la migration est compatible.

Vérifier que l’édition répond au besoin

Advanced Edition place un pool de connexions devant le cluster et utilise une élection du primaire par consensus. Les clients gardent le même point de connexion lorsque le primaire change. Les connexions actives peuvent cependant être interrompues : l’application doit se reconnecter et gérer le résultat incertain d’une transaction. Advanced prend en charge PostgreSQL 16, 17 et 18 ; les nouveaux clusters utilisent la version 18 par défaut. Architecture Advanced Edition

Choisissez cette édition si ses fonctions et son modèle de disponibilité justifient le coût pour votre application. La nouvelle prise en charge de pg_trgm ne justifie pas, à elle seule, la migration d’une petite base de développement. Vérifiez d’abord si l’édition actuelle répond déjà au besoin.

Les extensions ne sont pas le seul obstacle. Advanced ne propose actuellement ni l’importation en ligne, ni le déplacement géré vers une autre région, ni les CNAME personnalisés, ni le point de collecte externe compatible Prometheus. La migration en ligne DigitalOcean ne permet pas non plus de déplacer une base entre ses clusters gérés. Préparez un transfert de données testé séparément. Limites PostgreSQL actuelles

L’édition d’un cluster ne peut pas être modifiée après sa création. Confirmez ensemble l’édition, la version PostgreSQL, l’option CPU et la région. Les régions dépendent du forfait sélectionné ; une disponibilité PostgreSQL générale ne garantit pas la configuration Advanced voulue. Placez la cible près de l’application, dans le VPC approprié. Création du cluster et choix de région

Budgéter le cluster complet

Le tarif Advanced actuellement publié commence à 130 $ US par mois pour un primaire de 8 Gio de RAM et 2 vCPU. Les nœuds de secours et de lecture seule coûtent autant que le primaire. Pour cette configuration minimale :

Ce sont des calculs hors taxes et ressources supplémentaires, pas des factures mesurées ni des devis. Le prix de départ de 130 $ ne couvre pas deux nœuds. Le stockage Advanced supplémentaire est affiché à 0,115 $ US par Gio et par mois. Ajoutez les éventuels nœuds de lecture, les clusters temporaires, le chevauchement avec la source et l’hébergement applicatif. Tarifs PostgreSQL

Une autre échéance approche. Le 15 octobre 2026, Advanced doit recevoir des forfaits CPU partagé de 8 à 64 Gio. L’annonce n’en donne pas les prix ; ne leur appliquez pas le minimum actuel des nœuds dédiés.

À partir du 15 octobre, les comptes n’ayant jamais créé de cluster PostgreSQL ou MySQL ne pourront plus créer de cluster Standard dépassant 4 Gio, ni ajouter de nœuds de secours ou de lecture à ces nouveaux clusters. La restriction s’étend le 30 novembre à tous les comptes créant un nouveau cluster. Les clusters déjà créés ne sont pas concernés, notamment pour les opérations documentées de redimensionnement, restauration, duplication et ajout de nœuds. Un compte ayant créé puis supprimé un cluster relève de l’échéance de novembre. Annonce des changements de forfaits

Cette annonce ne justifie pas une migration précipitée d’une base existante. Si vous automatisez les créations, vérifiez séparément les changements d’API, Terraform ou doctl applicables à votre compte avant ces dates.

Tester une dépendance sur une cible isolée

Prévoyez environ 30 à 60 minutes pour un petit contrôle de compatibilité, en plus de la création du cluster et d’un exercice de restauration distinct. Il faut savoir administrer PostgreSQL, être autorisé à engager les frais, disposer de données de test approuvées et utiliser un client fondé sur libpq 16 ou ultérieur. Une migration réelle nécessite son propre créneau et un responsable.

Créez la cible seulement après avoir validé l’inventaire et le budget. Limitez les sources autorisées à l’application de test et à l’accès d’administration. N’ouvrez pas l’accès à 0.0.0.0/0. Utilisez une base vide et empêchez la copie applicative de déclencher des notifications, des tâches planifiées ou d’autres écritures de production.

Advanced utilise le magasin de certificats du système. Pour psql, activez la vérification complète et indiquez sslrootcert=system : la chaîne copiée depuis le panneau de contrôle n’ajoute pas automatiquement ce paramètre. Ne reprenez pas les instructions de téléchargement du certificat CA propres à Standard. Guide de connexion et TLS

Dans un terminal d’administration de confiance, remplacez les quatre valeurs ci-dessous par les paramètres de connexion de la cible de test. -W demande le mot de passe sans l’inscrire dans la commande. Cette commande ouvre une session ; elle ne crée ni cluster ni base.

psql --no-psqlrc --set=ON_ERROR_STOP=on -W \
  "host=YOUR_TEST_CLUSTER_HOST port=YOUR_TEST_CLUSTER_PORT dbname=YOUR_TEST_DATABASE user=YOUR_ADMIN_USER sslmode=verify-full sslrootcert=system"

Vérifiez d’abord la destination et la disponibilité de l’extension d’exemple :

SELECT current_database(), current_user;
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name = 'pg_trgm';

Cette vue est en lecture seule. Une valeur installed_version non nulle indique que l’extension est déjà installée dans cette base. Notez sa version sans supposer qu’elle correspond à la source. Vue des extensions disponibles

Si vous êtes dans la base vide de test prévue et que pg_trgm est disponible mais pas installé, exécutez :

CREATE SCHEMA extension_preflight;
CREATE EXTENSION pg_trgm WITH SCHEMA extension_preflight;
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'pg_trgm';
SELECT extension_preflight.similarity('hello', 'hello') = 1 AS trigrams_ok;

Ces commandes créent un schéma et chargent les objets de l’extension dans la base de test. Gardez ce schéma sous le contrôle de l’administrateur, sans droit d’écriture pour des rôles non fiables. La dernière requête doit renvoyer true : c’est le résultat attendu, pas un résultat observé. Arrêtez-vous si une étape échoue. IF NOT EXISTS ne prouve pas la compatibilité d’une extension déjà présente. Comportement de CREATE EXTENSION

Répétez le contrôle uniquement pour les dépendances nécessaires. Cette première base sert seulement à vérifier l’installation. Utilisez une autre base neuve pour la répétition de restauration, en respectant les schémas des objets d’extension, les droits et le search_path attendus par la source. Exécutez-y les vraies requêtes applicatives avec les données de test approuvées. L’installation réussie n’est que le premier contrôle.

Répéter la restauration avant de préparer la bascule

Restaurez une copie approuvée et protégée de la base dans une cible isolée. Choisissez un export et une restauration adaptés aux versions source et cible, puis contrôlez les extensions, propriétaires, droits, séquences et erreurs de restauration. pg_dump exporte une base cohérente ; les rôles et autres objets globaux demandent un traitement distinct. Un export logique ne réplique pas les écritures ultérieures. Documentation pg_dump

Consignez quelques critères d’acceptation :

• Chaque extension nécessaire est installée dans la bonne base, avec une version vérifiée.
• Les recherches, écritures, tâches de fond et contrôles de droits représentatifs fonctionnent.
• L’application vérifie TLS et se reconnecte après une coupure sans répéter une transaction.
• Une copie restaurée contient un enregistrement récent connu et accomplit une tâche applicative sans conséquence.
• Le temps de restauration mesuré tient dans le créneau prévu, avec un responsable de la décision.

Pendant l’exercice, la source reste seule à recevoir les écritures de production. Lors de la bascule réelle, arrêtez les écritures, produisez la copie finale cohérente, vérifiez la cible, puis redirigez les clients. Après les premières nouvelles écritures sur la cible, revenir simplement à l’ancienne base peut perdre ces changements ; il faut une réconciliation ou un retour inverse déjà éprouvé.

Vous pouvez décider lorsque l’intérêt de l’édition, la compatibilité des dépendances et le coût de la topologie complète sont établis, chevauchement de migration compris. Une extension manquante ou une restauration non vérifiée reste un obstacle explicite.

Les clients existants peuvent consulter les forfaits dans leur compte. Si DigitalOcean convient à un nouveau projet, consultez DigitalOcean (lien affilié), puis choisissez Databases et vérifiez la configuration complète avant tout achat.