PostgreSQL 19 Beta 2 est sortie le 16 juillet 2026, et c'est le moment où l'ensemble des fonctionnalités de la version 19 cesse de bouger et demande à être testé. Trois changements toucheront presque toutes les installations. REPACK remplace VACUUM FULL et CLUSTER sous un seul nom, et sait reconstruire une table sans verrou access exclusive. Le JIT est désormais désactivé par défaut, son calcul de coût ayant été jugé peu fiable. La compression TOAST par défaut passe de pglz à lz4. S'ajoute le support natif des requêtes de graphes SQL/PGQ, la fonctionnalité que peu de monde attendait dans Postgres. La liste des incompatibilités est plus longue que d'habitude, lisez-la avant de planifier la montée de version.
The short answer
PostgreSQL 19 Beta 2 est sortie le 16 juillet 2026. Le cycle de la version 19 apporte REPACK, qui unifie VACUUM FULL et CLUSTER et sait reconstruire des tables sans verrou access exclusive, le support natif des requêtes de graphes SQL/PGQ, le JIT désactivé par défaut après que son calcul de coût a été jugé peu fiable, et la compression TOAST par défaut qui passe de pglz à lz4. La Beta 2 elle-même est surtout faite de correctifs, dont plusieurs pour les nouveautés SQL/PGQ et FOR PORTION OF. La version finale est attendue vers septembre ou octobre 2026. La liste des incompatibilités est inhabituellement longue, planifiez la montée de version plutôt que de la supposer.
La plupart des annonces de bêta sont une formalité. Celle-ci mérite lecture, parce que l'intérêt de PostgreSQL 19 n'est pas une fonctionnalité que vous activez, ce sont deux valeurs par défaut qui changent sous vos pieds et une commande de maintenance qui porte enfin un nom sensé.
REPACK, ou la fin d'un accident de nommage
Pendant des années, Postgres a livré deux commandes faisant à peu près le même travail sous des noms qui ne disaient rien de leur différence. Les notes de version sont d'une franchise rafraîchissante sur le correctif : les deux anciennes commandes faisaient des choses similaires, mais sous des noms prêtant à confusion, le projet les a donc unifiées sous REPACK. VACUUM FULL et CLUSTER restent disponibles pour compatibilité, vos scripts et vos tâches cron continuent donc de fonctionner.
Ce qui compte au quotidien n'est pas le renommage. REPACK peut reconstruire des tables sans verrou access exclusive, via une option CONCURRENTLY. Quiconque a déjà planifié un VACUUM FULL comprend pourquoi cette ligne est la phrase la plus précieuse des notes de version. Récupérer l'espace d'une table gonflée a toujours voulu dire la mettre hors ligne, ce qui, sur une grosse table, signifie négocier une fenêtre avec des gens qui préféreraient que vous vous en absteniez. Faire le même travail sans verrou access exclusive change cette conversation.
Deux défauts qui vous trouveront
Le JIT est désormais désactivé par défaut. La raison donnée est que le JIT était auparavant activé par défaut et déclenché selon les coûts de l'optimiseur, mais que ce calcul de coût a été jugé peu fiable. L'aveu est notable, et il rejoint ce que beaucoup d'exploitants constataient : la compilation JIT se déclenchait parfois sur des requêtes où elle coûtait plus qu'elle ne rapportait. La conséquence est énoncée clairement dans les notes : les sites exécutant beaucoup de grosses requêtes analytiques doivent maintenant activer le JIT manuellement.
Cela coupe donc dans les deux sens. Si votre charge est transactionnelle, vous profitez probablement du nouveau défaut sans rien faire. Si vous exécutez de lourdes requêtes analytiques et que le JIT aidait réellement, vous devez le réactiver explicitement, et le confirmer par des mesures plutôt que par habitude.
Le second défaut est plus discret. La méthode de compression TOAST par défaut passe de pglz à lz4, plus efficace, par modification de la valeur par défaut de la variable default_toast_compression. Comme il s'agit d'un défaut et non d'une migration, vos données existantes ne sont pas réécrites et restent lisibles. Les nouvelles valeurs compressées, elles, passent en lz4.
Les graphes de propriétés arrivent dans Postgres
La fonctionnalité vedette est le support des requêtes de graphes de propriétés SQL, le standard SQL/PGQ, apporté par Peter Eisentraut et Ashutosh Bapat. Il faut être précis sur ce dont il s'agit, car le support des graphes dans une base relationnelle attire les attentes exagérées. Les notes de version précisent qu'en interne ces requêtes sont traitées comme des vues, elles sont donc écrites comme des requêtes relationnelles standard. C'est de la sémantique de graphe exprimée sur vos données relationnelles existantes, pas un nouveau moteur de stockage concurrent d'une base de graphes dédiée. Pour beaucoup d'équipes, c'est la version utile, puisque l'alternative consistait à déplacer les données vers un second système pour poser un seul type de question.
La Beta 2 inclut plusieurs correctifs pour cette nouvelle fonctionnalité SQL/PGQ, ce qu'une bêta est précisément censée produire.
Ce que la Beta 2 corrige elle-même
La Beta 2 est une version de correctifs posée sur la Beta 1, et la liste ressemble à une bêta en bonne santé. On y trouve un correctif pour une régression de vacuumdb avec analyze-in-stages sur les tables partitionnées, un correctif pour les workers REPACK non nettoyés lors d'une sortie FATAL, plusieurs correctifs pour la nouvelle syntaxe temporelle FOR PORTION OF qui ajoute des opérations sur des plages temporelles à UPDATE et DELETE, un correctif pour une condition de course quand l'activation du décodage logique est interrompue en parallèle, et un correctif pour le calcul du score d'âge multixact de l'autovacuum, qui pouvait devenir infini. Les formats de sortie non textuels de pg_dumpall ont été retirés.
Les incompatibilités sont le vrai travail
C'est ici qu'il faut ralentir. PostgreSQL 19 porte une liste de ruptures plus longue que d'habitude, et plusieurs sont appliquées par un pg_upgrade qui refuse de continuer, ce qui vaut mieux que de les découvrir plus tard.
Les dumps créés avec un pg_dump ou pg_dumpall antérieur à la version 19 utilisant standard_conforming_strings à off ne se chargeront pas correctement dans les serveurs 19 et suivants. Les retours chariot et sauts de ligne sont interdits dans les noms de base, de rôle et de tablespace, et pg_upgrade refusera de monter les clusters utilisant de tels noms. Les classes d'opérateurs d'index par défaut pour inet et cidr passent de btree_gist à GiST, et pg_upgrade refusera les clusters ayant des index btree_gist inet ou cidr. Au-delà des blocages de montée de version, le défaut de max_locks_per_transaction double de 64 à 128, et comme l'allocation de la taille des verrous a changé, les réglages existants doivent être doublés pour retrouver la capacité qu'ils avaient avant. CREATE SCHEMA ne réordonne plus les objets non schéma et respecte l'ordre que vous indiquez, sauf pour les clés étrangères qui sont créées en dernier. Les colonnes système ne peuvent plus être utilisées dans un COPY FROM avec une clause WHERE.
Quoi en faire maintenant
La consigne du projet donne le bon cadre. Les versions bêta ne sont pas conseillées en production, mais vous êtes encouragés à trouver des moyens d'exécuter vos charges applicatives habituelles sur cette bêta. Monter vers la Beta 2 depuis une version antérieure demande une stratégie similaire à une montée de version majeure normale, c'est-à-dire pg_upgrade ou un cycle dump et restauration.
Le geste concret : prenez votre base de préproduction la moins prestigieuse, dirigez vos vrais motifs de requêtes vers la 19 Beta 2, et vérifiez trois choses en particulier. Est-ce que désactiver le JIT par défaut a changé vos temps de requêtes analytiques. Est-ce que vos index inet ou cidr et d'éventuels noms d'objets exotiques vont bloquer pg_upgrade. Est-ce que votre réglage de max_locks_per_transaction signifie encore ce que vous croyez. Le découvrir en juillet est gratuit. Le découvrir en octobre ne l'est pas.
Sources et pour aller plus loin
Questions fréquentes
Quand PostgreSQL 19 sortira-t-il vraiment ?
La Beta 2 est arrivée le 16 juillet 2026. Le projet indique qu'il publiera d'autres bêtas selon les besoins des tests, puis une ou plusieurs versions candidates, jusqu'à la version finale attendue vers septembre ou octobre 2026. Cela vous laisse environ deux à trois mois pour tester vos propres charges de travail, ce qui est précisément l'objet d'une période de bêta. Rien de tout cela n'est destiné à la production pour l'instant.
Qu'est-ce que REPACK et remplace-t-il VACUUM FULL ?
REPACK est une nouvelle commande qui remplace à la fois VACUUM FULL et CLUSTER. Les notes de version expliquent le raisonnement sans détour : les deux anciennes commandes faisaient des choses similaires sous des noms prêtant à confusion, le projet les a donc unifiées sous REPACK. Les anciennes commandes restent disponibles pour compatibilité, rien ne casse à la montée de version. La partie vraiment utile est que REPACK peut reconstruire des tables sans verrou access exclusive via son option CONCURRENTLY, ce qui fait la différence entre une fenêtre de maintenance et un mardi ordinaire.
Pourquoi le JIT est-il désactivé par défaut, et faut-il le réactiver ?
Les notes de version sont directes. Le JIT était auparavant activé par défaut et déclenché selon les coûts de l'optimiseur, mais ce calcul de coût a été jugé peu fiable. En pratique, cela signifiait des requêtes compilées en JIT alors que l'opération ne rapportait rien, ajoutant de la latence au lieu d'en retirer. Le changement impose aux sites exécutant beaucoup de grosses requêtes analytiques d'activer le JIT manuellement. Si vous avez une charge de type entrepôt de données et que vous aviez mesuré un gain réel, réactivez-le volontairement et continuez à mesurer. Si vos requêtes sont transactionnelles ordinaires, le nouveau défaut est probablement ce que vous vouliez depuis le début.
Que change la compression TOAST pour les données existantes ?
PostgreSQL 19 change la méthode de compression TOAST par défaut, de pglz vers lz4, plus efficace, en modifiant la valeur par défaut de la variable serveur default_toast_compression. C'est un défaut, il gouverne donc les nouvelles valeurs compressées plutôt que de réécrire ce que vous avez déjà stocké. Les données existantes compressées en pglz restent lisibles. À noter que lz4 doit être disponible dans votre build, donc si vous compilez Postgres vous-même ou dépendez d'un paquet minimal, vérifiez ce point avant de supposer que le nouveau défaut s'applique.
Quelles incompatibilités vérifier avant la montée de version ?
Plusieurs, et c'est la partie à lire attentivement plutôt qu'à survoler. Les dumps créés par un pg_dump ou pg_dumpall antérieur à la version 19 avec standard_conforming_strings à off ne se chargeront pas correctement dans les serveurs 19 et suivants. Les retours chariot et sauts de ligne sont désormais interdits dans les noms de base, de rôle et de tablespace, et pg_upgrade refusera les clusters qui en utilisent. Les classes d'opérateurs d'index par défaut pour inet et cidr passent de btree_gist à GiST, et pg_upgrade refusera les clusters ayant des index btree_gist inet ou cidr. Le défaut de max_locks_per_transaction double, de 64 à 128, et comme l'allocation de la taille des verrous a changé, les réglages doivent maintenant être doublés pour retrouver leur capacité précédente.