PostgreSQL 19 introduit la réorganisation native des tables (repacking), davantage de contrôle sur les plans d’exécution et des améliorations de la réplication et de la maintenance. La disponibilité générale étant prévue pour le 19 novembre 2026, les équipes doivent évaluer ces avantages en tenant compte d’importantes limites de compatibilité et d’exploitation.
Une mise à niveau majeure de PostgreSQL peut modifier la façon dont une application interroge, maintient et réplique ses données. Ces changements peuvent améliorer les performances et réduire le travail d’exploitation. Ils peuvent aussi révéler des dépendances qui n’étaient pas évidentes avec une version antérieure. PostgreSQL 19 rend cette évaluation d’actualité.
Le PostgreSQL Global Development Group a publié PostgreSQL 19 RC1 le 15 octobre 2026. La RC2 est prévue pour le 12 novembre, et la disponibilité générale pour le 19 novembre, à condition qu’aucun problème bloquant pour la publication ne survienne. Une version candidate (release candidate) est en grande partie identique à la version finale prévue, même si certains correctifs peuvent encore être appliqués avant la disponibilité générale.
Au 6 novembre, PostgreSQL 19 reste une version candidate. Il s’agit d’une préversion, et les équipes doivent la tester en dehors de la production. La question utile pour les équipes de bases de données est de savoir quels changements méritent d’être testés avant la version finale.
Qu’est-ce qui change ?
PostgreSQL 19 apporte des améliorations à la maintenance des tables, à la planification des requêtes, à la réplication et à l’exploitation des bases de données.
| Capacité | Ce qui change | Ce que les équipes doivent évaluer |
|---|---|---|
REPACK natif | Réécrit les tables pour récupérer de l’espace disque | Verrouillage, besoins de stockage et visibilité des transactions |
pg_plan_advice | Influence certaines décisions du planificateur | Performances des requêtes et risque de conseils devenus obsolètes |
| Opérations de vacuum améliorées | Maintenance parallèle des index et meilleure priorisation | Consommation de ressources par la maintenance |
| Réplication logique | Synchronisation des séquences et activation plus souple | Comportement lors des migrations et des bascules (switchover) |
Commande WAIT sur un serveur secondaire (standby) | Attend une position donnée du journal de transactions (write-ahead log, WAL) | Cohérence des lectures, latence et gestion des délais d’expiration |
| Changements de compatibilité | Valeurs par défaut modifiées et fonctionnalités supprimées | Dépendances des applications, de l’authentification et des extensions |
Ces capacités répondent à des besoins différents. Les équipes doivent donner la priorité à celles qui répondent à un problème d’exploitation réel plutôt que de tester chaque fonctionnalité de la même manière.
Source : PostgreSQL 19 preliminary release notes.
1. Le REPACK natif offre une nouvelle option de maintenance
Les tables PostgreSQL peuvent accumuler de l’espace inutilisé à mesure que des lignes sont mises à jour ou supprimées. Un VACUUM ordinaire rend une grande partie de cet espace réutilisable, mais ne le restitue généralement pas au système d’exploitation. PostgreSQL 19 introduit la commande native REPACK, qui réécrit une table et ses index pour récupérer de l’espace. Elle peut aussi réorganiser les lignes selon un index.
L’option CONCURRENTLY permet une activité ordinaire sur la table pendant une grande partie de l’opération, ce qui évite le long verrou exclusif qu’exige une réécriture classique de la table. C’est utile, mais la réorganisation concurrente comporte des limites importantes.
Elle n’est pas sûre vis-à-vis de MVCC (MVCC-safe). MVCC (multiversion concurrency control, contrôle de concurrence multiversion) est le mécanisme qui permet à chaque transaction de travailler à partir d’un instantané (snapshot) cohérent des données. PostgreSQL avertit que les transactions qui utilisent des instantanés pris avant le début de l’opération de réorganisation peuvent voir la table comme vide après la validation (commit) de la transaction de réorganisation.
La réorganisation concurrente prend aussi un verrou exclusif pendant sa phase finale d’échange des fichiers. Elle nécessite suffisamment d’espace disque temporaire pour contenir une autre copie de la table et de ses index, et un stockage supplémentaire peut être nécessaire pour le tri et les modifications concurrentes.
D’autres restrictions s’appliquent. Par exemple, la réorganisation concurrente n’est pas disponible pour les tables partitionnées, les tables non journalisées (unlogged) et certaines tables dépourvues d’informations d’identité adaptées. Une réorganisation peut aussi échouer si des commandes DDL, qui modifient la structure d’une table, s’exécutent sur la table pendant l’opération, ou dans d’autres conditions documentées.
Pour ces raisons, elle ne doit pas être considérée comme un remplacement direct du VACUUM de routine. Les équipes de bases de données doivent d’abord tester des tables représentatives, la capacité disque disponible, le comportement des transactions, le verrouillage et les procédures de reprise. Lorsque la prévention du rebouclage des identifiants de transaction (transaction ID wraparound) est en jeu, PostgreSQL continue de recommander VACUUM, et non REPACK.
Ses apports
PostgreSQL 19 introduit la commande native REPACK, qui réécrit une table et ses index pour récupérer de l’espace. L’option CONCURRENTLY permet une activité ordinaire sur la table pendant une grande partie de l’opération, ce qui évite le long verrou exclusif qu’exige une réécriture classique de la table.
Ses limites
Elle n’est pas sûre vis-à-vis de MVCC (MVCC-safe). PostgreSQL avertit que les transactions qui utilisent des instantanés pris avant le début de l’opération de réorganisation peuvent voir la table comme vide après la validation (commit) de la transaction de réorganisation. La réorganisation concurrente prend aussi un verrou exclusif pendant sa phase finale d’échange des fichiers. Elle nécessite suffisamment d’espace disque temporaire pour contenir une autre copie de la table et de ses index, et un stockage supplémentaire peut être nécessaire pour le tri et les modifications concurrentes.
À tester
Les équipes de bases de données doivent d’abord tester des tables représentatives, la capacité disque disponible, le comportement des transactions, le verrouillage et les procédures de reprise. Lorsque la prévention du rebouclage des identifiants de transaction (transaction ID wraparound) est en jeu, PostgreSQL continue de recommander VACUUM, et non REPACK.
Source : PostgreSQL 19, REPACK command documentation.
2. La planification des requêtes devient plus contrôlable
PostgreSQL choisit normalement les plans d’exécution à l’aide de statistiques, d’estimations de coût et de règles de l’optimiseur. Il arrive que ses estimations aboutissent à un plan peu performant pour une charge de travail particulière. PostgreSQL 19 introduit le module pg_plan_advice, qui permet aux équipes de décrire et d’influencer certaines décisions du planificateur (planner). L’extension associée pg_stash_advice peut rattacher des conseils enregistrés à des requêtes individuelles.
Ces outils peuvent aider les équipes à analyser des régressions de plan ou à stabiliser un plan dont l’utilité est connue. Cependant, les conseils de plan ne remplacent pas l’optimiseur de requêtes. Ils agissent en restreignant les choix dont dispose le planificateur. Ils ne peuvent pas forcer PostgreSQL à utiliser un plan que le planificateur juge invalide ou qu’il ne génère pas.
Les conseils peuvent aussi devenir néfastes lorsque la distribution des données, les index ou les caractéristiques de la charge de travail changent. Par exemple, un conseil qui favorise un index particulier peut aider une requête aujourd’hui mais devenir inefficace une fois que la table sous-jacente a fortement grossi.
La bonne approche consiste à partir de statistiques fiables, d’index appropriés et de l’analyse des requêtes. Les conseils au planificateur ne doivent être introduits que là où des éléments probants reproductibles le justifient. Les équipes doivent aussi vérifier dans la durée que les conseils fournis restent applicables.
Sources : PostgreSQL 19, pg_plan_advice documentation et PostgreSQL 19 preliminary release notes.
3. La réplication devient plus souple
PostgreSQL 19 introduit des changements susceptibles de simplifier certains flux de réplication et de migration. L’une des améliorations permet aux abonnés (subscribers) de la réplication logique de maintenir les valeurs des séquences alignées sur celles du publieur (publisher). Cela peut être utile lors de migrations où les identifiants générés doivent continuer correctement après une bascule.
PostgreSQL 19 permet aussi d’activer la réplication logique, dans les conditions prises en charge, lorsque wal_level vaut replica, sans le redémarrage auparavant associé à la modification de ce paramètre. Ces changements réduisent une partie du travail de configuration et de migration, mais ils ne dispensent pas de vérifier la synchronisation, la cohérence des données ou le comportement en cas de basculement (failover). Une autre amélioration notable concerne la cohérence des lectures sur les serveurs secondaires.
La commande WAIT et la cohérence read-your-writes
En réplication asynchrone, une écriture peut être validée sur le serveur primaire (primary) avant qu’un serveur secondaire ne l’ait rejouée. Une application qui lit immédiatement sur le serveur secondaire peut donc voir des données plus anciennes. PostgreSQL 19 introduit WAIT FOR LSN, qui permet à une application d’attendre qu’une position donnée du journal de transactions soit atteinte. Un numéro de séquence de journal (log sequence number, LSN) identifie une position dans le journal de transactions.
Pour obtenir un comportement read-your-writes (lire ses propres écritures), l’application doit obtenir une position WAL appropriée auprès du serveur primaire après la validation de la transaction concernée, puis attendre que cette position soit rejouée sur le serveur secondaire. La distinction entre un WAL écrit, vidé sur disque (flushed) et rejoué est importante. Seul un rejeu (replay) réussi établit que les modifications validées concernées sont disponibles pour les lectures suivantes sur ce serveur secondaire.
Commit au primaire
En réplication asynchrone, une écriture peut être validée sur le serveur primaire (primary) avant qu’un serveur secondaire ne l’ait rejouée. Une application qui lit immédiatement sur le serveur secondaire peut donc voir des données plus anciennes.
Lire la position WAL
Pour obtenir un comportement read-your-writes (lire ses propres écritures), l’application doit obtenir une position WAL appropriée auprès du serveur primaire après la validation de la transaction concernée, puis attendre que cette position soit rejouée sur le serveur secondaire.
Attente secondaire
PostgreSQL 19 introduit WAIT FOR LSN, qui permet à une application d’attendre qu’une position donnée du journal de transactions soit atteinte. L’attente peut aussi ajouter de la latence. La commande prend en charge la gestion d’un délai d’expiration, mais un délai omis ou égal à zéro peut entraîner une attente indéfinie.
Puis lire
Seul un rejeu (replay) réussi établit que les modifications validées concernées sont disponibles pour les lectures suivantes sur ce serveur secondaire. Les applications doivent gérer correctement les délais d’expiration, la promotion du serveur secondaire et les interruptions de la restauration (recovery).
L’attente peut aussi ajouter de la latence. La commande prend en charge la gestion d’un délai d’expiration, mais un délai omis ou égal à zéro peut entraîner une attente indéfinie. Les applications doivent gérer correctement les délais d’expiration, la promotion du serveur secondaire et les interruptions de la restauration (recovery). Il s’agit d’un mécanisme de cohérence utile, et non d’un substitut à la supervision de la réplication ou à la gestion des défaillances au niveau de l’application.
Source : PostgreSQL 19, WAIT documentation.
4. Améliorations de la maintenance et des performances
PostgreSQL 19 améliore aussi la façon dont les bases de données effectuent leurs tâches de fond. Les changements comprennent une priorisation plus souple de l’autovacuum et une maintenance parallèle des index, ainsi que des améliorations de la planification, de l’exécution et des E/S.
Ces améliorations peuvent aider certaines charges de travail, mais leurs effets dépendent de la taille des tables, du nombre d’index, de la configuration et des ressources disponibles. Le vacuum parallèle, par exemple, concerne principalement les phases de vacuum des index et de nettoyage des index. Il ne rend pas toutes les opérations de vacuum parallèles et ne garantit pas une exécution plus rapide.
De même, une priorisation plus élaborée de l’autovacuum ne dispense pas de surveiller la croissance des tables et l’avancement de la maintenance. Les équipes doivent mesurer la durée de la maintenance, l’utilisation des E/S, la latence des requêtes et la contention des ressources avant et après la mise à niveau. Les notes de version décrivent les capacités, mais les performances en production doivent être démontrées sur des charges de travail représentatives.
Source : PostgreSQL 19, Routine Vacuuming.
5. Les changements de compatibilité méritent une attention particulière
Plusieurs changements de PostgreSQL 19 peuvent affecter les applications existantes et les outils d’exploitation.
| Changement | Conséquence possible |
|---|---|
| Compilation JIT (just-in-time, à la volée) désactivée par défaut | Certaines charges de travail analytiques peuvent nécessiter une configuration JIT explicite |
| Authentification RADIUS supprimée | Les installations qui utilisent RADIUS doivent migrer vers une autre méthode d’authentification prise en charge |
standard_conforming_strings toujours activé | Les anciens scripts SQL ou dumps de bases de données qui reposent sur l’ancien comportement peuvent nécessiter des modifications |
Classes d’opérateurs d’index par défaut modifiées pour inet et cidr | pg_upgrade refuse les clusters qui ont des index btree_gist sur ces types, ces clusters nécessitent donc d’abord des corrections |
| Changements des interfaces système et de la configuration | Les outils de supervision, les extensions ou l’automatisation peuvent nécessiter des mises à jour de compatibilité |
Un point particulièrement important concerne les dumps (sauvegardes logiques) de bases de données. PostgreSQL avertit que les dumps créés avec d’anciennes versions de pg_dump ou pg_dumpall alors que standard_conforming_strings était désactivé peuvent ne pas se charger correctement dans PostgreSQL 19. Les équipes doivent utiliser un processus de dump pris en charge et vérifier la restauration plutôt que de supposer qu’une ancienne sauvegarde est compatible.
Les notes de version signalent aussi des cas où pg_upgrade refusera de mettre à niveau des clusters contenant certains index ou noms d’objets incompatibles. Une mise à niveau de version majeure exige une stratégie de migration appropriée, comme pg_upgrade, un dump suivi d’une restauration, ou une approche adaptée fondée sur la réplication logique. Mettre à jour les paquets comme s’il s’agissait d’une version mineure ne suffit pas.
Source : PostgreSQL 19, Migration and Compatibility Notes.
Que doivent tester les équipes de bases de données dès maintenant ?
Une évaluation utile de la version candidate peut rester ciblée.
Compatibilité des applications : exécutez des tests applicatifs et d’intégration représentatifs sur PostgreSQL 19 RC1. Incluez le comportement SQL, l’authentification, les extensions et les pilotes de bases de données.
Requêtes critiques : comparez les plans d’exécution et les performances réelles des requêtes qui ont une incidence sur l’activité de l’entreprise.
Comportement de la maintenance : testez REPACK et les améliorations du vacuum sur des données représentatives. Incluez l’utilisation du disque, le verrouillage, le comportement des anciens instantanés et les conditions d’échec.
Réplication : validez la synchronisation des séquences, le comportement de WAIT sur le serveur secondaire, la latence et la gestion des erreurs lorsque ces fonctionnalités vous concernent.
Migration et reprise : répétez à blanc la méthode de mise à niveau prise en charge, vérifiez que les sauvegardes peuvent être restaurées et documentez la procédure de reprise en cas d’échec de la migration.
Compatibilité applicative
Exécutez des tests applicatifs et d’intégration représentatifs sur PostgreSQL 19 RC1. Incluez le comportement SQL, l’authentification, les extensions et les pilotes de bases de données.
Requêtes clés
Comparez les plans d’exécution et les performances réelles des requêtes qui ont une incidence sur l’activité de l’entreprise.
Maintenance
Testez REPACK et les améliorations du vacuum sur des données représentatives. Incluez l’utilisation du disque, le verrouillage, le comportement des anciens instantanés et les conditions d’échec.
Réplication
Validez la synchronisation des séquences, le comportement de WAIT sur le serveur secondaire, la latence et la gestion des erreurs lorsque ces fonctionnalités vous concernent.
Migration et reprise
Répétez à blanc la méthode de mise à niveau prise en charge, vérifiez que les sauvegardes peuvent être restaurées et documentez la procédure de reprise en cas d’échec de la migration.
Hors production
Ces tests doivent se dérouler en dehors de la production. L’annonce de la RC1 indique que d’autres correctifs peuvent encore être appliqués avant la disponibilité générale : une version candidate ne constitue donc pas une base pour des charges de travail de production.
Ces tests doivent se dérouler en dehors de la production. L’annonce de la RC1 indique que d’autres correctifs peuvent encore être appliqués avant la disponibilité générale : une version candidate ne constitue donc pas une base pour des charges de travail de production.
Qu’en est-il des installations PostgreSQL existantes ?
Toutes les organisations n’ont pas besoin de PostgreSQL 19 immédiatement. Les équipes qui utilisent déjà des versions de PostgreSQL prises en charge doivent continuer à appliquer les mises à jour de sécurité tout en évaluant si la mise à niveau majeure apporte une réelle valeur d’exploitation.
PostgreSQL 14 demande une attention plus immédiate. Le projet PostgreSQL a fixé la fin du support communautaire de la version 14 au 12 novembre 2026.
Les organisations qui utilisent encore PostgreSQL 14 doivent donner la priorité au passage à une version prise en charge. Cela ne signifie pas nécessairement attendre PostgreSQL 19 ni l’adopter dès le jour de sa sortie.
Source : PostgreSQL versioning policy.
La portée pratique de PostgreSQL 19
PostgreSQL 19 apporte des améliorations utiles pour la maintenance des bases de données, le contrôle de la planification des requêtes et la réplication. Cette version introduit aussi des changements de comportement qui exigent des tests délibérés. La réorganisation native peut récupérer de l’espace, mais le fonctionnement concurrent comporte d’importantes contraintes de visibilité des transactions et de ressources. Les conseils au planificateur peuvent aider à traiter des requêtes difficiles, mais peuvent devenir néfastes lorsque les charges de travail changent. Les améliorations de la réplication offrent davantage de contrôle, mais exigent toujours une gestion rigoureuse de la cohérence et des défaillances.
Les équipes de bases de données devraient profiter de la période de version candidate pour vérifier quelles améliorations bénéficient à leurs charges de travail et quels changements exigent une préparation avant une mise à niveau en production.
Références et lectures complémentaires
- PostgreSQL Global Development Group, PostgreSQL 19 RC1 Released. 15 octobre 2026.
- PostgreSQL 19 Release Notes. Détails préliminaires sur les fonctionnalités et la compatibilité.
- PostgreSQL 19 REPACK Documentation. Exigences d’exploitation et avertissement sur MVCC.
- PostgreSQL 19 pg_plan_advice Documentation. Comportement et limites du planificateur.
- PostgreSQL 19 WAIT Documentation. Cohérence sur les serveurs secondaires et comportement des délais d’expiration.
- PostgreSQL 19 Routine Vacuuming. Comportement du vacuum et de la maintenance parallèle.
- PostgreSQL Versioning Policy. Versions prises en charge et dates de fin de support.
Vérification des sources : 6 novembre 2026. PostgreSQL 19 reste une version candidate, et les pages de documentation de PostgreSQL 19 citées ici sont des préversions. Les dates du 12 novembre pour la RC2 et du 19 novembre pour la disponibilité générale sont prévues, et non des publications confirmées. Les fonctionnalités et les détails de compatibilité doivent être revérifiés par rapport à la documentation de la version finale avant la publication publique.