Introduction
La bêta 1 de PostgreSQL 19 est sortie le 4 juin 2026, avec une version finale attendue pour septembre 2026. Comme à chaque nouvelle version majeure, c'est l'occasion de scruter les changements qui vont réellement impacter notre quotidien de prestataires PHP/Symfony. Dans son article "My Three Top PostgreSQL 19 Features", Stefanie Janine Stölting (ProOpenSource OÜ) met en avant trois nouveautés qui ont attiré notre attention chez MulerTech — pas pour leur côté spectaculaire, mais parce qu'elles traduisent une maturité croissante de PostgreSQL sur les opérations de maintenance en production, sans interruption de service.
Chez MulerTech, nous recommandons PostgreSQL à la grande majorité de nos clients pour leurs projets Symfony. Cette version 19 confirme que ce choix continue de payer, notamment sur un point qui nous tient particulièrement à cœur : la capacité à maintenir une base de données « à chaud », sans bloquer les sessions actives.
REPACK : la réorganisation de tables sort enfin de l'ombre des extensions
Jusqu'à présent, réorganiser physiquement une table pour récupérer l'espace disque fragmenté ou retrouver un ordre physique cohérent nécessitait l'extension externe pg_repack. Une solution efficace, mais qui imposait une dépendance supplémentaire à installer, maintenir et faire valider par les équipes infra — un vrai irritant quand on travaille avec des hébergeurs managés ou des environnements contraints.
Avec PostgreSQL 19, REPACK devient une commande native. Et surtout, elle supporte le paramètre CONCURRENTLY, sur le même principe que CREATE INDEX CONCURRENTLY ou REINDEX CONCURRENTLY : la réorganisation peut s'exécuter sans verrouiller les sessions en cours sur la table concernée.
Concrètement, cela signifie :
- plus besoin d'installer et de surveiller une extension tierce ;
- une opération de maintenance lourde (compactage, défragmentation) qui ne bloque plus les écritures applicatives ;
- la possibilité de préciser un index pour trier physiquement la table, ou de laisser PostgreSQL s'appuyer sur l'ordre défini par un CLUSTER existant.
Pour des applications Symfony à fort trafic, où la moindre fenêtre de maintenance doit être négociée avec le métier, ce genre de fonctionnalité change vraiment la donne. On gagne en autonomie opérationnelle, sans sacrifier la disponibilité. 🛠️
INSERT ... ON CONFLICT ... SELECT : un nouvel outil pour gérer les conflits d'unicité
La deuxième nouveauté concerne la clause ON CONFLICT des instructions INSERT. Jusqu'ici, deux comportements étaient disponibles en cas de conflit (typiquement une violation de contrainte unique) : DO NOTHING, qui ignore silencieusement la ligne en conflit, et DO UPDATE, qui permet de mettre à jour la ligne existante (le fameux « upsert »).
PostgreSQL 19 ajoute une troisième option : DO SELECT. Au lieu d'ignorer ou de modifier la ligne en conflit, on peut désormais simplement la récupérer. Cela ouvre des scénarios bien plus riches pour la logique applicative : on peut par exemple insérer une nouvelle entité métier, et si elle existe déjà, récupérer ses données actuelles dans le même aller-retour avec la base, sans avoir à enchaîner un second SELECT ou à gérer une exception applicative.
Pour les équipes qui développent avec Doctrine ou des requêtes SQL natives dans Symfony, c'est une simplification appréciable : moins de code défensif autour des cas de doublons, moins de round-trips réseau, et une logique métier plus lisible directement portée par la base de données.
Pourquoi cela compte dans nos choix d'architecture
Ces deux fonctionnalités n'ont l'air, à première vue, que des détails techniques. Mais elles illustrent une tendance de fond qui justifie notre confiance dans PostgreSQL pour les projets de nos clients : l'écosystème internalise progressivement des opérations qui nécessitaient autrefois des extensions tierces, des scripts maison, ou des fenêtres de maintenance planifiées.
Le support de CONCURRENTLY sur REPACK s'inscrit dans une longue série d'efforts (CREATE INDEX CONCURRENTLY, REINDEX CONCURRENTLY, et désormais REPACK) qui rendent les opérations de maintenance compatibles avec des exigences de disponibilité continue. C'est exactement le type de garantie que nous devons pouvoir offrir à nos clients qui exploitent des applications critiques, où chaque minute d'indisponibilité a un coût réel.
Quant à ON CONFLICT ... DO SELECT, elle réduit la complexité du code applicatif nécessaire pour gérer des cas pourtant très courants (synchronisation de données, import idempotent, gestion de doublons), ce qui se traduit directement par moins de bugs et une maintenance plus simple sur le long terme.
Conclusion
PostgreSQL 19 n'est encore qu'en version bêta — la version stable est attendue pour septembre 2026 — mais ces premières fonctionnalités confirment une trajectoire qui nous convient parfaitement chez MulerTech : un moteur de base de données qui gagne en robustesse opérationnelle sans complexifier l'expérience développeur.
Comme le rappelle Stefanie Janine Stölting dans son article original, la phase de bêta est aussi le moment où la communauté peut faire la différence : tester les versions candidates, signaler les bugs, contribuer à la stabilité de la version finale. Nous suivrons avec attention l'évolution de ces fonctionnalités jusqu'à la sortie officielle, et ne manquerons pas de partager nos retours d'expérience une fois la version 19 disponible en production.
Article source original (en anglais) : « My Three Top PostgreSQL 19 Features » par Stefanie Janine Stölting, ProOpenSource OÜ — https://postgr.es/p/9lz
