PostgreSQL 19 entre dans la dernière ligne droite : la première release candidate est disponible depuis le 15 octobre 2026, et la version finale est prévue pour le 19 novembre 2026. C’est le bon moment pour tester vos requêtes, vos sauvegardes et vos pipelines de données sur la nouvelle version, avant qu’elle n’arrive dans les dépôts de production.
- PostgreSQL 19 RC 1 est sortie le 15 octobre 2026, presque identique à la future version stable.
- Une RC 2 est prévue le 12 novembre, puis la disponibilité générale le 19 novembre, sauf imprévu.
- Nouveautés phares : la commande REPACK, l’extension pg_plan_advice et la réplication logique activable sans redémarrage.
- Plusieurs incompatibilités sont à vérifier avant migration, dont le retrait de RADIUS.
Plan de l'article
Où en est le calendrier de PostgreSQL 19 ? #
Selon l’annonce officielle du PostgreSQL Global Development Group, cette RC 1 sera « pour l’essentiel identique » à la version initiale. Quelques correctifs peuvent encore s’ajouter d’ici la sortie.
À lire Extrait Kbis : comment l’obtenir et à quoi sert-il ?
Le calendrier comporte une particularité cette année. La prochaine mise à jour des versions maintenues, le 12 novembre, embarquera de nombreux correctifs. L’équipe de publication a choisi de les intégrer dans PostgreSQL 19 avant sa sortie : une deuxième release candidate paraîtra donc le même jour. La version stable suivra le 19 novembre, si aucun problème n’impose un nouveau report.
Qu’est-ce qui a changé depuis la beta 4 ? #
Les corrections de la dernière phase de test portent surtout sur les nouveautés de la version. La commande REPACK (CONCURRENTLY) et l’extension pg_plan_advice ont reçu plusieurs correctifs, tout comme les nouvelles optimisations du planificateur qui s’appuient sur le fait qu’une expression peut valoir NULL ou non.
Un détail intéressera ceux qui exportent des données vers des outils d’analyse : COPY (requête) TO ... (FORMAT json) utilise désormais les noms de colonnes de la requête, alias compris, comme clés JSON, et non plus ceux de la table. Si vous alimentez un tableau de bord ou un script Python avec ces exports, vos clés suivront enfin vos alias.
D’autres correctifs touchent l’autovacuum parallèle, l’import de statistiques de postgres_fdw et l’activation automatique de la réplication logique. La liste complète figure sur la page des points ouverts du wiki PostgreSQL.
Quelles nouveautés pour les développeurs et les équipes data ? #
Les notes de version de PostgreSQL 19 mettent en avant plusieurs chantiers.
REPACK pour récupérer de l’espace
La nouvelle commande REPACK récupère l’espace disque et réorganise le contenu d’une table, ce qui peut accélérer les requêtes. Sa variante CONCURRENTLY fonctionne sans bloquer les lectures ni les écritures. Jusqu’ici, ce besoin passait par des extensions tierces ou par un VACUUM FULL bloquant.
Guider le planificateur
L’extension pg_plan_advice permet d’orienter les choix du planificateur de requêtes, et pg_stash_advice applique ces consignes automatiquement selon la requête. Pour une requête analytique qui part soudain sur un mauvais plan, c’est un outil de dépannage longtemps réclamé.
Réplication et lecture sur les secondaires
La réplication logique peut maintenant être activée sans redémarrer le serveur lorsque wal_level vaut replica, et les valeurs de séquences sont répliquées. La nouvelle commande WAIT apporte une cohérence « read-your-writes » sur les serveurs secondaires : une application peut écrire sur le primaire puis relire sa donnée sur un réplica sans risquer une version périmée.
À lire Piloter ses flux d’envoi : choisir son logiciel de routage emailing
Côté performances, le projet cite l’ajustement automatique du nombre de processus d’entrées-sorties, des contrôles de clés étrangères plus rapides, ainsi que l’autovacuum parallèle des index avec un nouveau système de priorité.
Que vérifier avant de migrer ? #
Passer de PostgreSQL 18 à 19 demande une stratégie de mise à jour majeure, avec pg_upgrade ou pg_dump et pg_restore, comme l’explique la documentation de mise à niveau. Les notes de version listent plusieurs ruptures de compatibilité :
| Changement | Ce qu’il faut regarder |
|---|---|
| Support RADIUS supprimé | Toute authentification qui en dépend doit changer de méthode. |
| Avertissement après connexion MD5 | Prévoir le passage à SCRAM, MD5 étant déjà déprécié depuis la version 18. |
standard_conforming_strings toujours actif |
Les anciens dumps réalisés avec ce paramètre à off ne se rechargeront pas correctement. |
json_array() sans ligne |
Renvoie un tableau JSON vide au lieu de NULL : à tester dans le code applicatif. |
| Noms avec retour chariot interdits | Bases, rôles et tablespaces concernés bloquent pg_upgrade. |
Le cas de json_array() est le plus sournois pour les développeurs : un test du type « si le résultat est nul » peut changer de comportement sans aucune erreur visible.
Et pour ceux qui utilisent PgBouncer ? #
La même semaine, le gestionnaire de connexions PgBouncer 1.26.1 a corrigé trois failles. La plus grave, CVE-2026-107350, permet à un client connaissant le mot de passe d’un utilisateur SCRAM de se connecter sous l’identité d’un autre, administrateurs compris. Les deux autres provoquent une boucle infinie déclenchable sans authentification. La mise à jour est recommandée, en relisant le réglage ignore_startup_parameters, dont le comportement change.
À lire Comment fiabiliser les emails de gestion d’une PME sans perdre de clients ?
Questions fréquentes #
Peut-on utiliser PostgreSQL 19 RC 1 en production ?
Ce n’est pas recommandé : une release candidate sert aux tests. Des correctifs arriveront encore avec la RC 2 du 12 novembre.
Quand sortira la version stable de PostgreSQL 19 ?
Le projet vise le 19 novembre 2026, sauf si un problème impose un report ou une release candidate supplémentaire.
Faut-il tout réécrire pour migrer ?
Non, mais il faut passer par pg_upgrade ou un dump/restore, et tester les points d’incompatibilité listés dans les notes de version.
