PostgreSQL 19 Beta 2 : les changements à tester avant la version finale

PostgreSQL 19 se rapproche de sa forme définitive. Publiée le 16 juillet 2026, la Beta 2 corrige des problèmes détectés dans la première bêta et donne aux équipes une base plus stable pour évaluer les changements de performances, d'observabilité et de compatibilité attendus dans la version finale.

Le projet reste explicite : cette version de développement ne doit pas être exécutée en production. Son utilité est ailleurs. En la confrontant dès maintenant à une copie anonymisée des schémas, des requêtes et des volumes réels, une équipe peut identifier les régressions et préparer son prochain cycle de migration sans mettre les données en danger.

La réponse rapide

La Beta 2 n'est pas un signal pour planifier un basculement immédiat. C'est le moment de construire un rapport reproductible qui permettra de décider après la sortie stable, annoncée par le projet autour de septembre ou octobre 2026.

Ce que corrige précisément la Beta 2

Cette deuxième bêta réunit les corrections accumulées depuis la Beta 1. Le projet cite notamment des correctifs pour les opérations temporelles FOR PORTION OF, les requêtes de graphes de propriétés SQL/PGQ, une condition de concurrence dans le décodage logique et une régression lors de l'analyse de tables partitionnées.

Des ajustements concernent également le score utilisé par l'autovacuum, ainsi que plusieurs erreurs ou plantages. Ces changements illustrent la raison d'être d'une bêta : l'interface et le comportement peuvent encore évoluer jusqu'à la version finale. Un résultat obtenu aujourd'hui doit donc être enregistré avec la version exacte du serveur et reproduit sur les versions suivantes.

Tester la Beta 2 a malgré tout de la valeur. Un plan de requête problématique, une incompatibilité d'extension ou un changement de comportement signalé pendant cette période peut être analysé avant que PostgreSQL 19 ne devienne stable.

Les gains de performance à mesurer sur vos charges

Les notes de version décrivent plusieurs optimisations, mais aucune ne garantit un gain uniforme. PostgreSQL 19 peut transformer certaines expressions NOT IN en anti-jointures, pousser des agrégats avant une jointure et améliorer les stratégies de semi-jointure. Ces décisions peuvent réduire fortement le travail sur certaines requêtes analytiques, tout en produisant peu de différence sur d'autres.

La bonne comparaison repose sur les plans réels. Pour chaque requête critique, il faut conserver EXPLAIN (ANALYZE, BUFFERS, WAL, SETTINGS), le temps d'exécution, les lectures, les écritures temporaires et la variance sur plusieurs passages. Une moyenne isolée sur une machine froide est insuffisante.

Le moteur ajoute aussi de la lecture anticipée aux entrées-sorties asynchrones. Le bénéfice potentiel dépend du stockage, de la taille du jeu de données et du taux de cache. Un SSD local, un volume réseau et une base presque entièrement en mémoire ne réagiront pas de la même manière.

COPY en formats texte et CSV bénéficie d'optimisations SIMD sur les processeurs compatibles. Les équipes qui ingèrent des fichiers volumineux doivent mesurer à la fois le débit, l'utilisation CPU et la pression sur le journal WAL. Un import plus rapide peut simplement déplacer le goulot d'étranglement vers le stockage ou les réplicas.

Autovacuum parallèle et nouvelle visibilité

PostgreSQL 19 introduit la possibilité d'exécuter plusieurs traitements autovacuum en parallèle. Cette évolution vise les installations où la maintenance accumule du retard sur des ensembles de tables importants. Elle ne dispense pas d'observer le volume de tuples morts, les délais de gel et la concurrence avec les transactions applicatives.

La nouvelle vue pg_stat_autovacuum_scores expose les scores utilisés pour classer les tâches. Elle peut aider à comprendre pourquoi une table est traitée avant une autre et à repérer une table qui monopolise la capacité de maintenance. Le test doit simuler les écritures habituelles, pas seulement exécuter un VACUUM manuel sur une base inactive.

Le journal des attentes de verrouillage devient également plus visible puisque log_lock_waits est activé par défaut selon les notes de version. La vue pg_stat_lock complète cette observation, tandis que pg_stat_recovery apporte des informations sur la récupération. Avant d'activer la version en production, il faudra estimer le volume supplémentaire de journaux et adapter leur collecte.

LZ4 par défaut : mesurer la taille et le coût CPU

La compression TOAST par défaut passe à LZ4. TOAST stocke et compresse les valeurs trop grandes pour tenir directement dans une ligne, comme certains textes, documents JSON ou contenus binaires. LZ4 privilégie généralement la vitesse, mais le résultat dépend fortement des données.

Une base de test représentative doit comparer la taille des tables et index, le temps d'insertion, les lectures et la consommation CPU. La compression choisie pour les colonnes existantes ne change pas magiquement chaque valeur déjà stockée : le protocole doit distinguer un chargement neuf, une restauration et l'évolution progressive de données existantes.

Ce changement mérite une attention particulière sur les bases où le stockage est coûteux ou où de gros champs JSON sont très sollicités. Il ne faut pas conclure à partir d'une table synthétique remplie d'une chaîne répétitive, beaucoup plus compressible que les données réelles.

Les incompatibilités à inventorier avant toute migration

PostgreSQL 19 comporte plusieurs changements qui peuvent toucher l'exploitation. Le serveur avertit davantage autour de l'authentification MD5, RADIUS est retiré, standard_conforming_strings reste toujours actif, la compilation JIT est désactivée par défaut et max_locks_per_transaction passe par défaut à 128.

Certaines applications peuvent aussi observer une différence avec les tableaux JSON vides. Les utilisateurs de btree_gist sur des colonnes inet ou cidr doivent consulter attentivement les notes de migration, car certains index peuvent bloquer pg_upgrade et nécessiter une reconstruction.

L'inventaire doit inclure :

• les extensions et leurs versions disponibles pour PostgreSQL 19 ;
• les méthodes d'authentification et les règles pg_hba.conf ;
• les paramètres explicitement modifiés par l'équipe ;
• les types et index non standards ;
• les pilotes utilisés par chaque application ;
• les outils de sauvegarde, de réplication, de supervision et de pool de connexions.

Une base qui démarre n'est pas nécessairement compatible. Il faut exécuter les migrations applicatives, les tests d'intégration, les tâches planifiées et les procédures d'exploitation.

Un laboratoire de test en six étapes

Le projet PostgreSQL recommande de tester les charges habituelles. Un protocole pratique peut tenir en six étapes :

1. créer une infrastructure isolée qui ne peut pas recevoir de trafic de production ;
2. restaurer une sauvegarde récente après anonymisation des données sensibles ;
3. installer les mêmes extensions et paramètres que sur la version actuelle ;
4. rejouer les requêtes critiques et un profil d'écriture représentatif ;
5. comparer performances, plans, verrous, journaux et taille de stockage ;
6. documenter chaque différence avec un cas reproductible et la version exacte.

Les tests doivent inclure une panne contrôlée, une restauration, un redémarrage, un retard de réplication et une saturation de connexions. Une migration réussie ne se limite pas au débit nominal : elle doit préserver la capacité à diagnostiquer et à restaurer le service.

Choisir le chemin de migration, puis tester le retour arrière

Une migration majeure de PostgreSQL exige une stratégie dédiée. Les options documentées sont la sauvegarde suivie d'une restauration, pg_upgrade ou la réplication logique. Le bon choix dépend du volume, de la fenêtre d'indisponibilité, des extensions et de la capacité à maintenir temporairement deux environnements.

pg_upgrade réduit souvent la durée du basculement, mais demande une préparation précise des binaires, extensions et index. La réplication logique peut diminuer l'interruption visible, au prix d'une architecture plus complexe et d'une vérification soigneuse des objets répliqués. Une restauration complète est simple à raisonner, mais peut être trop longue pour de gros volumes.

Le retour arrière doit être testé avant le jour du changement. Une fois que l'application a écrit dans la nouvelle version, remettre l'ancien serveur en service sans perdre de données n'est pas automatique. La procédure doit fixer le point de non-retour, les critères d'abandon et le responsable de la décision.

Ce que la bêta permet de préparer dès maintenant

PostgreSQL 19 Beta 2 ne doit héberger aucune donnée de production, mais elle offre un calendrier utile. Les équipes peuvent établir leur matrice de compatibilité, qualifier leurs extensions, créer un corpus de requêtes et automatiser les mesures qui seront répétées sur la version candidate puis sur la version finale.

Le résultat attendu n'est pas une date de migration prématurée. C'est un dossier contenant les gains mesurés, les régressions, les changements de configuration, la procédure de basculement et le plan de retour arrière. Lorsque PostgreSQL 19 sera stable, la décision reposera alors sur des données propres à l'infrastructure plutôt que sur une liste générique de nouveautés.