Une équipe prépare une migration vers PostgreSQL 19 parce qu’un prototype dépend d’une fonction de graphe prévue dans cette version. Puis la bêta 4 arrive et cette fonction n’y figure plus. Le risque n’est pas seulement de découvrir une incompatibilité tard : c’est d’avoir construit une feuille de route, un contrat d’architecture ou une estimation autour d’une capacité qui n’est pas dans la version candidate.
Le PostgreSQL Global Development Group a publié PostgreSQL 19 bêta 4 le 24 septembre 2026. L’annonce indique que plusieurs fonctionnalités prévues ont été retirées après évaluation et que certains détails peuvent encore changer pendant la bêta. Elle présente la bêta comme une version destinée aux essais, en amont de la disponibilité générale. L’événement invite donc à revoir les hypothèses de projet, pas à annoncer une version stable ni à migrer directement une production.
Une version de test n’est pas une promesse de fonctionnalités
Une bêta permet aux équipes de tester une version en développement et de signaler des problèmes. Elle n’offre pas le même contrat qu’une version majeure publiée comme stable. Dans son annonce du 24 septembre, le projet PostgreSQL explique que la bêta 4 révoque plusieurs changements initialement envisagés pour PostgreSQL 19. Le prochain jalon était alors annoncé comme une release candidate attendue début octobre ; le projet précisait que la date de disponibilité générale pouvait dépendre des tests et évaluations. Au 1er octobre 2026, la page officielle de test bêta liste encore la bêta 4 comme version courante : la release candidate reste une étape prévue, pas une version déjà confirmée sur cette page.
Parmi les retraits cités figurent le support SQL/PGQ pour les requêtes de graphe de propriétés, les opérations temporelles FOR PORTION OF, l’activation et la désactivation en ligne des sommes de contrôle, ainsi que des opérations de fusion et division de partitions. L’annonce mentionne aussi le retrait de fonctions de génération de DDL (pg_get_role_ddl(), pg_get_tablespace_ddl() et pg_get_database_ddl()). Les notes de version PostgreSQL 19 sont à consulter de nouveau à chaque qualification. Il faut les décrire comme des éléments retirés de cette bêta après avoir été prévus, et non comme des fonctions retirées d’une version stable déjà adoptée.
La motivation communiquée par le projet est de préserver la fiabilité et un calendrier de release prévisible en laissant davantage de temps au développement et à la revue. C’est l’explication officielle. Un projet utilisateur peut en tirer une conséquence pratique : lorsque la fiabilité est prioritaire, il vaut mieux traiter les fonctionnalités de préversion comme des hypothèses jusqu’à ce qu’elles figurent dans la version et la documentation de référence retenues.
Chercher les dépendances avant de modifier la feuille de route
Commencez par inventorier les éléments qui utilisent la version cible. Cherchez les fonctions et syntaxes de la liste de retraits dans les migrations, requêtes, extensions, scripts d’exploitation, outils de sauvegarde et tests d’intégration. Une dépendance peut être indirecte : une bibliothèque peut générer une requête, ou un outil interne peut appeler une fonction de DDL sans que le code applicatif la nomme directement.
Classez les résultats en trois catégories : une fonctionnalité indispensable à l’application ; une amélioration optionnelle qui peut attendre ; un essai qui n’a pas encore de consommateur en production. Pour chacune, notez le propriétaire, l’environnement utilisé, la raison métier, la solution de repli et l’impact si la capacité est absente. Cette liste vous évite de confondre « nous avions prévu de l’essayer » et « notre service ne démarre plus sans elle ».
| Hypothèse projet | Vérification à faire | Décision possible |
|---|---|---|
| SQL/PGQ pour un parcours graphe | Repérer requêtes, extensions et dépendances qui supposent cette syntaxe | Reporter le parcours ou garder une solution existante |
FOR PORTION OF pour les données temporelles |
Examiner les migrations et règles de mise à jour des périodes | Maintenir la logique actuelle jusqu’à une version confirmée |
| Changement de checksums en ligne | Identifier les procédures d’exploitation qui en dépendent | Conserver les étapes documentées pour la version retenue |
| Fusion ou division de partitions | Vérifier les automatisations et le plan de maintenance | Garder un script alternatif validé sur un clone |
Cette matrice est un outil de cadrage, pas une matrice de compatibilité publiée par PostgreSQL. Les comportements exacts sont à confirmer dans les notes de version et la documentation associée.
Qualifier la bêta sans exposer de données réelles
Si votre organisation teste PostgreSQL 19, utilisez une instance jetable et des données synthétiques ou suffisamment anonymisées. Documentez la version précise, l’extension chargée, les réglages, le schéma et l’origine de chaque jeu d’essai. Rejouez les migrations sur une copie dédiée, vérifiez les sauvegardes et les restaurations, puis exécutez les cas représentatifs : lectures, écritures concurrentes, contraintes, index, partitionnement et plans de requête utiles à votre service.
Pour une fonction retirée, le test doit aussi vérifier le comportement attendu en son absence. Une migration qui échoue immédiatement est une preuve claire d’une dépendance ; une fonctionnalité absente mais inutilisée peut seulement invalider une expérimentation. N’essayez pas de reconstituer un résultat en ajoutant une fonction maison ou une extension non prévue au périmètre sans le signaler : cela ferait passer pour un test PostgreSQL standard ce qui est en réalité une variante de votre plateforme.
Une mise à niveau majeure PostgreSQL requiert une stratégie appropriée, telle que pg_upgrade ou un transfert avec pg_dump et pg_restore, selon l’annonce et la documentation officielle. Le choix dépend de la version source, des extensions, des contraintes de disponibilité et des procédures de restauration. Il faut l’évaluer sur un environnement représentatif. Cet article ne décrit aucune migration réellement exécutée et ne propose aucune procédure de production.
Décider avec une porte de sortie
Pour chaque capacité envisagée, consignez son état : disponible dans la bêta courante, retirée de cette bêta, ou encore sujette à changement. Ajoutez la source et la date de vérification. Révisez ensuite les dépendances et l’effort estimé. Une décision de migration ne devrait avancer que lorsque la version cible, les extensions requises, les migrations de schéma et les procédures de retour sont compatibles avec les besoins réels.
La bêta 4 rappelle que les notes de conception et les annonces intermédiaires ne sont pas des contrats de disponibilité. Au 1er octobre 2026, consultez les notes de version 19 et la page du projet avant de figer une décision ; le calendrier de release candidate évoqué le 24 septembre pouvait encore évoluer. Préparer une qualification hors production est utile. Remplacer une version stable par une bêta dans un service qui exige la fiabilité ne découle pas de cette annonce. La feuille de route doit suivre les capacités effectivement présentes dans la version que vous choisirez, avec un chemin de retour si le test invalide une hypothèse.
Sources vérifiées le 1er octobre 2026
- PostgreSQL Global Development Group, « PostgreSQL 19 Beta 4 Released! », publié le 24 septembre 2026 : statut de la bêta, retraits, calendrier prévisionnel de release candidate et recommandations de test/mise à niveau.
- PostgreSQL, notes de version 19, consultées le 1er octobre 2026 : référence à vérifier pour le contenu évolutif de la version.
- PostgreSQL, Beta Information, consulté le 1er octobre 2026 : la bêta 4 est encore listée comme version courante à la date de consultation.
La situation de migration et les dépendances de la matrice sont des exemples fictifs. Aucune installation, migration ni procédure de restauration n’a été exécutée pour cet article.