Les nouveautés de Postgres 19 : analyse approfondie de la bêta

• Une bêta riche en améliorations sur tous les fronts — requêtes de graphes de propriétés SQL, réplication logique, VACUUM, performances, etc. — avec l’intégration native dans le cœur de REPACK CONCURRENTLY pour les grandes bases de données de production
• La prise en charge de la fusion et de la division des partitions, ainsi que la synchronisation des valeurs de séquence, facilitent nettement les changements de conception et les déplacements de données en exploitation
• L’autovacuum introduit des workers parallèles et un système de scores de priorité, améliorant le débit et la visibilité des tâches de maintenance
• L’arrivée de SQL/PGQ permet d’interroger des données existantes sous forme de graphe sans abandonner le modèle relationnel
• Plus qu’une fonctionnalité phare isolée, c’est surtout la largeur du périmètre qui ressort, avec des progrès simultanés sur les applications, l’exploitation, les performances et l’extensibilité

---

Intégration native de REPACK

• Dans les environnements exploités de longue date, le besoin de récupérer le bloat des tables, de réécrire une table ou de réorganiser les données sans subir les verrous de VACUUM FULL ou CLUSTER revient régulièrement
  • Un écosystème d’extensions existait déjà pour répondre à ce problème, notamment pg_repack, qui comblait ce manque
• Postgres 19 introduit la commande REPACK dans le cœur, avec prise en charge de REPACK CONCURRENTLY
  • Cette fonctionnalité devrait intéresser davantage les utilisateurs en production que ne l’imaginent les lecteurs habituels des notes de version

Une partitionnement plus pratique

• Postgres 19 ajoute la prise en charge de la fusion et de la division des partitions
• Les stratégies de partitionnement sont choisies avec des informations imparfaites, et quand la charge, la durée de rétention ou le rythme de croissance des données changent, certaines partitions peuvent devenir trop grosses ou trop petites
• Le fait de pouvoir fusionner et diviser laisse la possibilité de faire évoluer la conception dans le temps sans tout reconstruire depuis le début
  • Fusion de partitions Q1 et Q2 en une seule partition : ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
  • Un exemple de SPLIT PARTITION est également donné pour découper une partition Q3 au mois

La maturité de la réplication logique

• La réplication logique est utile pour les migrations, les mises à niveau, les systèmes de reporting, les déplacements de données, la réplication sélective, la haute disponibilité et les workflows d’exploitation
• L’amélioration la plus importante est la synchronisation des valeurs de séquence, qui aligne mieux l’abonné sur l’éditeur
  • Sans réplication de l’état des séquences, les données sont bien transférées, mais le prochain ID généré peut se désaligner après le cutover
  • La publication prend désormais en charge ALL SEQUENCES, le signalement des erreurs de synchronisation de séquence et un meilleur comportement lors des actualisations d’abonnement liées aux séquences
• Il devient possible d’utiliser la clause EXCEPT pour publier toutes les tables tout en en excluant certaines
• wal_level = replica active automatiquement la réplication logique si nécessaire, et le nouveau effective_wal_level indique le comportement réellement appliqué, ce qui réduit les erreurs de configuration et améliore la visibilité

Un autovacuum plus intelligent et plus visible

• L’autovacuum peut utiliser des workers de vacuum parallèles, avec un contrôle global et par table
  • Exemple de configuration globale : ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
• Un nouveau système de scores pour déterminer l’ordre dans lequel les tables sont vacuumées améliore la priorisation des tables les plus urgentes
  • Exemple d’ajustement du poids par table : urgence de vacuum basée sur les insertions à 3.0, urgence de vacuum classique update/delete à 0.5
• La nouvelle vue pg_stat_autovacuum_scores rend visible le processus de décision
  • Des détails supplémentaires dans les vues de progression de vacuum et d’analyse, l’usage mémoire et le parallélisme dans VACUUM VERBOSE et les logs d’autovacuum, ainsi qu’un log_autoanalyze_min_duration dédié renforcent l’observabilité de la maintenance

Arrivée des requêtes de graphes de propriétés SQL

• Ajout de SQL/PGQ (SQL property graph queries)
  • Les charges de travail où le modèle sommet/arête est utile incluent la détection de fraude, les recommandations, l’analyse réseau, les graphes de permissions, la supply chain ou les organigrammes
  • Exemple de définition de graphe de propriétés : CREATE PROPERTY GRAPH store_graph avec spécification de VERTEX TABLES et EDGE TABLES
• L’idée n’est pas d’abandonner le modèle relationnel, mais d’ajouter une autre manière d’interroger des données déjà présentes
  • Cela s’inscrit dans la même logique que JSONB, la recherche plein texte ou les extensions, qui n’imposaient pas de changer d’architecture existante
• Du point de vue des développeurs, cela permet d’utiliser des requêtes de type graphe sans ajouter un datastore séparé, un chemin de synchronisation, une surface d’exploitation supplémentaire ou un nouveau sujet de debug à 2 heures du matin

Un COPY plus utile

• COPY FROM prend désormais en charge le saut de plusieurs lignes d’en-tête
  • Utile pour traiter des CSV exportés par des fournisseurs, des outils internes ou d’autres sources avec des métadonnées supplémentaires en tête
• COPY FROM ajoute ON_ERROR SET_NULL, qui remplace les valeurs d’entrée invalides par null, offrant une alternative entre « tout l’import échoue » et « nettoyage préalable obligatoire »
  • Un exemple est donné pour charger un fichier où la colonne price contient des valeurs comme 'N/A' et 'MISSING'
• COPY TO peut désormais produire du JSON, y compris un tableau JSON unique, et exporter directement des tables partitionnées (alors qu’auparavant il fallait COPY (SELECT ...))
  • Exemple d’export d’une table vers un tableau JSON valide : WITH (FORMAT JSON, ARRAY true)

Améliorations de confort côté SQL

• GROUP BY ALL groupe automatiquement les expressions de la liste cible qui ne sont ni agrégées ni des fenêtres, ce qui rend les SQL exploratoires et les requêtes de reporting plus propres
• Les fonctions de fenêtre prennent en charge IGNORE NULLS et RESPECT NULLS pour lead, lag, first_value, last_value et nth_value
• L’ajout de INSERT ... ON CONFLICT DO SELECT ... RETURNING permet de renvoyer plus directement la ligne en conflit dans les upserts
• UPDATE et DELETE FOR PORTION OF poursuivent la prise en charge des opérations temporelles, avec notamment l’extension des fonctions temporelles RANDOM()

Des gains de performance généralisés

• Le planificateur et l’exécuteur progressent sur de nombreux points : anti-join, semi-join, constant folding, tri incrémental sur les chemins append, agrégations avant jointure, calcul de sélectivité des jointures, statistiques sur les fonctions, etc.
• Postgres évolue pour mieux reconnaître les formes courantes de requêtes et réduire le travail inutile
  • Certaines agrégations peuvent être réalisées avant la jointure, réduisant le nombre de lignes traitées
  • Davantage de cas de NOT IN et LEFT JOIN sont transformés en anti-join efficaces
  • Meilleure visibilité de Memoize dans EXPLAIN, amélioration du tri avec radix sort, contrôles de clés étrangères plus rapides, et utilisation d’instructions SIMD pour les entrées texte et CSV de COPY FROM
• Dans de nombreux cas, une simple mise à niveau suffit pour obtenir un meilleur comportement sans modifier le code applicatif

Pourquoi Postgres 19 est important

• Ce n’est pas une fonctionnalité unique qui se démarque, mais bien la largeur du périmètre
  • Pour les développeurs d’applications : requêtes de graphe, syntaxe SQL enrichie, améliorations des fonctions de fenêtre, meilleur comportement des upserts
  • Pour les opérateurs : REPACK CONCURRENTLY, autovacuum amélioré, monitoring renforcé, changement de checksum en ligne, visibilité accrue sur la réplication
  • Pour les utilisateurs focalisés sur les performances : améliorations du planificateur, SIMD, visibilité sur l’I/O asynchrone, contrôles de clés étrangères plus rapides, tri amélioré
  • Pour ceux qui construisent sur Postgres : nouveaux hooks, module de conseil au planificateur, améliorations des extensions, récupération des statistiques FDW, poursuite des investissements dans l’écosystème d’extensions
• Il ne progresse pas seulement pour une charge de travail ou un persona donné, mais simultanément comme base de données et plateforme pour les applications, l’exploitation, l’analyse et l’extension
• Ce n’est pas encore une version GA, donc c’est le bon moment pour tester : exécuter les applications, valider les migrations, vérifier les extensions, examiner les plans des requêtes clés et passer en revue les workflows de réplication logique et de maintenance

[GN⁺]

Commentaires sur Hacker News

• J’ai utilisé Postgres, Oracle, MS SQL Server et MySQL dans des projets réels, et même si je n’ai pas utilisé SQLite en profondeur, je sais que c’est une excellente option.
  Aujourd’hui, pour mes propres besoins, j’évite systématiquement Oracle et MySQL/MariaDB.
  Postgres est excellent, mais j’aimerais qu’il dispose de connexions légères et de vues matérialisées mises à jour de manière synchrone. Même si les poolers de connexions améliorent la situation, l’usage mémoire par connexion concurrente reste anormalement élevé, et une fonctionnalité comme les vues indexées de SQL Server permet, dans des contextes de données complexes, des implémentations élégantes, triviales et toujours correctes.
  SQL Server peut être coûteux, mais dans beaucoup de cas il vaut son prix, et choisir soigneusement son entrepôt de données permet d’éviter beaucoup de futurs maux de tête.

  • Pour les problèmes de stockage relationnel, j’utilise surtout SQLite et MSSQL.
    Si l’on veut utiliser une option gratuite, il est difficile de faire mieux que SQLite, qui couvre aujourd’hui la plupart des cas d’usage. En revanche, il commence à montrer ses limites côté sauvegarde, réplication et outillage. Si je dois être responsable de la disponibilité du système et de la reprise après sinistre, cela ne me dérange pas de payer pour réduire le risque.
    Si je dois payer ne serait-ce qu’un peu, autant aller jusqu’au bout. L’expérience développeur autour de MSSQL est sans équivalent, et je trouve que SSMS et les projets SQL de Visual Studio sont largement meilleurs que les solutions de type Entity Framework actuelles. Avec des outils tiers comme ceux de RedGate, on peut remplacer des packages de consulting à plusieurs millions de dollars.
    Je ne proposerais pas de déployer un nouveau serveur Oracle ou DB2, mais s’il en existe déjà un, je m’opposerais jusqu’au bout à une refonte visant à s’en débarrasser. Ces bases de données s’accompagnent généralement d’une énorme quantité d’histoires d’horreur, et tenter de reproduire leurs effets de bord bizarres dans un nouveau moteur peut, faute d’autre option, casser l’activité elle-même.
  • Oracle, c’est une combinaison de douleur, de souffrance, de coûts élevés, de procès et de misère humaine. Sans les cadres intermédiaires non techniques qui aiment recevoir des avantages comme de bonnes fêtes en achetant des logiciels coûteux, l’entreprise aurait probablement déjà disparu.
  • Même Microsoft semble avoir plus ou moins abandonné SQL Server et consacrer davantage de temps à améliorer ses différents produits Postgres sur Azure. Depuis 2022, la dernière version majeure s’est surtout contentée d’ajouter quelques fonctions d’IA.
    En tant que DBA, quand on fait beaucoup de travaux DBA lourds, Postgres joue dans une autre catégorie que SQL Server. Postgres est natif Linux et open source, donc en matière de flexibilité, d’observabilité interne et d’exploitation, SQL Server ne soutient pas la comparaison.
    Dans le paysage technologique actuel, je considère SQL Server comme pratiquement mort. Les entreprises qui l’utilisent sont surtout des organisations legacy centrées sur Windows, et elles sont de moins en moins nombreuses.
  • J’aimerais vraiment avoir des vues matérialisées à rafraîchissement synchrone. Dans la terminologie Oracle, cela semble correspondre à quelque chose comme « rafraîchissement au commit ».
    Ce serait aussi bien d’avoir une option de rafraîchissement différé. L’idée serait de traiter plusieurs mises à jour en une seule fois en ne prenant en compte que les enregistrements modifiés depuis le dernier rafraîchissement, même si je ne sais pas exactement comment Oracle le fait techniquement. Cette fonctionnalité serait un ajout fantastique par rapport à presque toutes les bases OLTP open source.
    Le projet OrioleDB m’intrigue aussi beaucoup : https://github.com/orioledb/orioledb/releases
    Il y a quelques années, j’ai pas mal souffert à cause du vacuum, avec beaucoup d’insertions et de suppressions aléatoires continues dans une sorte de table temporaire. J’ai résolu le problème en accumulant davantage de changements en RAM avant de les flusher dans la table afin d’augmenter le nombre de lignes modifiées par page, mais trouver le bon équilibre a été très pénible.
  • PostgreSQL est un meilleur produit, mais il n’a pas la scalabilité horizontale de MySQL/MariaDB. Donc si l’on a besoin d’un cluster facile à configurer, par exemple pour une grande boutique de vente en ligne, MySQL reste utile.

• Ayant utilisé Postgres pendant plus de 15 ans dans le domaine scientifique, je commence à m’inquiéter de l’absence de stockage orienté colonnes dans PostgreSQL.
  À mesure que les jeux de données grossissent, les limites du stockage de PG se font de plus en plus sentir. Plusieurs extensions comme cetus peuvent fournir cette fonctionnalité, mais on devient alors dépendant de la prise en charge future de l’extension, tout en augmentant la complexité.

  • C’est un peu de promotion sans gêne, mais je travaille depuis quelques mois sur ce problème sous forme d’extension : https://github.com/xataio/deltax
    Au départ, je pensais qu’utiliser des tables Postgres comme stockage et l’exécuteur Postgres introduirait trop de surcharge intrinsèque, et qu’égaler les performances de Timescale serait déjà assez impressionnant. Je ne pensais pas qu’on pourrait se rapprocher d’une base de données analytique dédiée.
    Mais à mesure que le projet avançait, les performances ont continué à s’améliorer, et je suis désormais clairement favorable à l’idée de faire de l’analytique avec Postgres + une extension.
  • Si c’est ce que vous attendez, vous avez peut-être choisi la mauvaise base de données. Les bases de données orientées colonnes constituent une catégorie distincte.
    C’est un peu comme s’inquiéter qu’Apple ne vende pas de machines à laver.
  • Du point de vue de l’informatique, je ne vois pas bien comment une base transactionnelle pourrait implémenter un modèle en colonnes. À grande échelle, une combinaison comme Postgres + CDC + ClickHouse, avec une vraie base analytique, me semble être l’option la plus solide.
  • Si les jeux de données grossissent, il me semble préférable de garder les nouvelles données dans PostgreSQL et d’archiver régulièrement les anciennes dans une base de données de type data warehouse, afin de maintenir Postgres à une taille réduite.
    De nos jours, beaucoup d’entreprises utilisent aussi, dans leur application principale, une base clé-valeur ou un stockage documentaire en complément d’une base relationnelle.
  • En tant qu’utilisateur depuis 25 ans, l’état actuel me va. Plus ne veut pas forcément dire mieux, il suffit de regarder Redis.

• Je ne comprends pas pourquoi il n’a pas été question du fait que PostgreSQL 19 introduit la prise en charge native des données temporelles application-time fondée sur le standard SQL:2011 : https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

  • Je suis surpris que l’article original ne le mentionne pas. Avant, on implémentait ça en ajoutant manuellement des triggers tcn et des tables fantômes _archive : https://www.postgresql.org/docs/current/tcn.html
    Si ça devient natif, ce sera probablement excellent, comme la plupart des implémentations PostgreSQL
  • Dommage aussi que les Query Hints ne soient évoqués qu’en passant. Il y avait eu une discussion intéressante sous un précédent article au titre similaire
    https://news.ycombinator.com/item?id=48413655
  • C’est une fonctionnalité chouette, mais honnêtement je pense qu’elle est un peu délicate à bien utiliser. Et il faut faire attention à ce que les PII ne restent pas longtemps quelque part dans le vide temporel

• Je n’arrive pas à savoir si cet article emploie un style surreprésenté dans les données d’entraînement des LLM, ou s’il a été beaucoup retravaillé avec l’IA. Je penche pour la seconde hypothèse

  • « Retravaillé » est une formulation bien trop généreuse. Ce qui me gêne davantage, c’est que les informations sur l’auteur induisent en erreur. On ne trouve pas craig-kerstiens chez Hugging Face, et aucune phrase de cet article ne donne l’impression d’avoir été tapée directement au clavier
    Quand Claude écrit des phrases du genre « en tant que personne qui fait X depuis longtemps », j’y vois une forme d’échec d’alignement. Un LLM ne devrait pas écrire comme s’il avait une expérience personnelle. Des humains ont peut-être parlé ainsi dans les données d’entraînement, mais même s’il s’agit d’une séquence de tokens statistiquement plausible, je pense qu’un LLM ne devrait pas revendiquer des expériences de vie qu’il n’a pas
  • Inutile d’être charitable à ce point. Snowflake a licencié des rédacteurs techniques en disant vouloir les remplacer par l’IA : https://snowflake.help/snowflake-layoffs-2026-technical-writ...
  • Ce genre de commentaires à faible effort qui critiquent le style et la mise en forme va à l’encontre des guidelines de discussion de Hacker News, et il faudrait prendre des mesures pour nettoyer les commentaires. Ça devient ridicule
  • Pangram juge que ce texte est entièrement généré par IA, mais je ne sais pas à quel point on peut faire confiance à Pangram. J’aimerais aussi connaître l’avis des autres
  • Je comprends que deviner si de l’IA a été utilisée soit à la mode. Mais s’il y a quelque chose à critiquer, je pense qu’il est plus utile de critiquer le résultat final

• J’aime bien les améliorations de COPY et de la réplication logique. Actuellement, je sauvegarde ma base PG dans une instance Databasus en side-car, et celle-ci est plus lourde que tout le backend + la DB + Caddy
  Ce qui suit est une plainte sur le style LLM
  À lire des phrases comme « Cela suffit à le montrer : les utilisateurs avaient un vrai besoin, et l’écosystème a comblé ce vide », « Cela paraît simple, mais résout de vrais problèmes d’exploitation », « Cela ne change pas le monde, mais améliore les workflows de données du quotidien », si Orwell était encore en vie, il aurait peut-être déclaré son analphabétisme en anglais et appris le klingon

• Les fonctionnalités de base de données graphe ont l’air intéressantes, mais la syntaxe GRAPH_TABLE est vraiment atroce
  SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
  Ça rappelle neo4j, mais je ne pense pas que ce soit quelque chose qu’un outil sérieux devrait copier tel quel en 2026
  Au final, ce qui m’intéresse, c’est la vitesse. La sécurité au niveau des lignes est une fonctionnalité très utile, mais tenter de construire quelque chose de sérieux avec l’implémentation de Postgres est téméraire. Le planner part en vrille et fait du matching ligne par ligne, ce qui détruit les performances

  • Ce n’est pas une syntaxe arbitraire inventée par Postgres
    C’est SQL/PGQ, dérivé du langage Cypher de Neo4J et désormais intégré au standard SQL
  • Tu dis que, pour la sécurité au niveau des lignes, le planner vérifie ligne par ligne ? C’est précisément ça, la Row-level security. Comment veux-tu vérifier autrement si une ligne satisfait la policy ?

• J’aimerais que PostgreSQL ajoute non seulement la compression de lignes, mais aussi la compression de blocs. La compression de lignes seule a un effet trop limité
  On peut mettre les données dans un pool ZFS et activer la compression de blocs, mais une prise en charge native réduirait la charge de configuration et pourrait aussi offrir de meilleures performances

• GROUP BY ALL est vraiment logique quand on y pense, et c’est amusant parce que je n’y avais jamais songé auparavant

• D’un point de vue plutôt DevOps, j’aimerais vraiment que PostgreSQL prenne enfin en charge les mises à niveau sur place entre versions majeures consécutives
  La plupart des distributions peuvent gérer la contrainte pénible qui consiste à faire tourner l’ancienne et la nouvelle version côte à côte pour pg_upgrade, mais avec Docker, passer à une nouvelle version majeure est vraiment douloureux

• Je suis content que GROUP BY ALL arrive. À ma connaissance, c’est un concept introduit par DuckDB
  La documentation de DuckDB indique aussi que plusieurs fonctionnalités ont d’abord été introduites dans DuckDB, puis adoptées par d’autres systèmes, comme GROUP BY ALL
  https://duckdb.org/docs/lts/sql/dialect/friendly_sql