PostgreSQL Conference Europe 2025
2025-11-05
2216 mots, 11 minutes de lecture
2025-11-05
2216 mots, 11 minutes de lecture
Retour sur la PostgreSQL Conference Europe 2025
Cette année, la PostgreSQL Conference Europe 2025 s’est déroulée à Riga, en Lettonie. Cet évènement autour de PostgreSQL rassemble le plus grand nombre de participants en Europe.
La liste des conférences est disponible sur le site de l’évènement : https://2025.pgconf.eu/. Les supports de présentations, ainsi que les enregistrements vidéos sont également mis à disposition dans la mesure du possible.
Community events day
Le mardi, pour la première fois cette année, était consacré à la communauté.
La journée était découpée en ateliers d’une demi-journée. Les ateliers étaient aussi divers qu’intéressants.
Le nombre de places était limité, ce qui a engendré un peu de frustration.
De nombreuses interventions d’une dizaine de minutes devaient permettre de dresser un état des lieux des opérateurs autour de PostgreSQL. Malheureusement, la plupart des présentations ont été consacrées à l’opérateur CloudNativePG.
Celui-ci présente toutefois un réel intérêt, puisqu’il est désormais complètement libre.
Un atelier à destination des organisateurs de conférences communautaires, avec des conseils intéressants, et des retours d’expérience.
Encore une preuve, s’il en fallait que la communauté est active et accueillante.
La conférence
Lors de la première intervention de la journée, Magnus Hagander a évoqué le nombre de 650 participants. Encore une très nombreuse audience cette année.
La conférence d’ouverture est donnée par Karen Sandler, de la Software Freedom Conservancy. Le sujet abordé est celui de l’importance des logiciels libres dans le monde actuel.
Les conférences sont ensuite réparties dans différentes salles, avec 4 conférences simultanées, dont une réservée aux sponsors. Nous résumons ici nos notes à propos des présentations auxquelles nous avons assisté.
Performance
L’oratrice Melanie Plageman évoque les travaux entrepris depuis des années pour améliorer le freeze des tuples visibles : de nombreuses tentatives ont été abandonnées, car les solutions expérimentées ne sont pas toujours meilleures que la situation actuelle.
Pour rappel, le freeze d’un tuple visible consiste à oublier la transaction ayant rendu visible la ligne, permettant ainsi le cycle des identifiants de transaction. Un des inconvénients de ces tâches de maintenance est l’amplification en écriture : une même page de données est écrite plusieurs fois si nécessaire, à chaque itération des maintenances.
Finalement, la solution retenue, et livrée avec la version 18 de PostgreSQL, est de freezer autant que possible les lignes pendant un vacuum régulier, diminuant l’amplification en écriture.
L’orateur Andres Freund est l’auteur principal d’une nouvelle fonctionnalité de PostgreSQL 18 : les entrées-sorties asynchrones.
Après un rappel des enjeux et des possibilités de cette fonctionnalité, il nous montre les gains potentiels, en intégrant dans le test les travaux en cours pour les futures versions de PostgreSQL.
En effet, si la fonctionnalité actuelle est limitée aux lectures séquentielles et aux lectures « bitmap » des index, les lectures indexées et les écritures sont prévues pour les versions 19, 20 ou 21 de PostgreSQL.
L’orateur Tomas Vondra est un développeur habituel de PostgreSQL et s’est trouvé confronté à un problème de performance d’une requête utilisant un grand nombre de partitions. Cela l’a amené à se pencher sur la façon dont les verrous sont obtenus lors de l’exécution d’une requête, et en particulier le « fast-path locking ». Apparue dans la version 9.2 de PostgreSQL, cette fonctionnalité permet d’avoir un cache local de la table des verrous, mais seulement pour 16 objets, ce qui pose un problème lorsqu’il y a un grand nombre de partitions : les verrous sont alors notés dans la mémoire partagée, ce qui est plus lent.
Tomas Vondra travaille alors pour proposer une solution permettant de noter un plus grand nombre de verrous dans ce cache local : la proposition, présente dans PostgreSQL 18, consiste à utiliser un « set-associative cache » afin d’augmenter le nombre d’entrées possibles avec le même niveau de performance.
L’orateur constate alors le gain de performance, très visible dans les Flame Graphs présentés. Pour terminer, outre la liste de toutes les possibilités que cela ouvre pour les prochaines versions de PostgreSQL, Tomas Vondra remercie l’auteur original de la fonctionnalité, Robert Haas, qui a livré un code de qualité, facilitant les améliorations proposées par la suite, et ce détail est très important pour comprendre pourquoi PostgreSQL est un bon outil : il est bien écrit !
L’orateur Lukas Fittl explique en quoi une nouvelle fonctionnalité de PostgreSQL 18 lui a permis de reprendre une idée déjà présente, mais en l’améliorant pour la rendre utilisable.
La nouveauté de PostgreSQL 18 est la possibilité pour une extension de stocker un identifiant de plan d’exécution, ce qui permet de suivre un même plan au cours de l’exécution d’une requête, à travers les différents « hooks » de PostgreSQL. À cela s’ajoute la possibilité pour une extension d’utiliser des statistiques cumulatives.
L’extension pg_stat_plans
permet alors de suivre l’utilisation des plans d’exécution par les requêtes
d’une instance PostgreSQL, permettant ainsi des analyses fines des
performances de nos requêtes, sans grever les performances de ces dernières.
L’orateur Boriss Mejias revient sur un sujet couramment abordé dans les conférences PostgreSQL, mais toujours nécessaire : la gestion de la concurrence dans PostgreSQL.
La présentation revient sur tous les éléments importants qui sont la conséquence de l’implémentation de MVCC dans PostgreSQL : l’isolation des transactions, la notion de lignes mortes, les raisons pour lesquelles VACUUM est utile et a des conséquences, y compris sur la réplication et le freeze des tuples visibles.
Administration
L’orateur Jan Wieremjewicz détaille le besoin exprimé par de plus en plus d’utilisateurs de PostgreSQL : le chiffrement transparent des données, ou TDE.
Entre autres besoins, il nous rappelle que, pour des raisons règlementaires, le chiffrement sur disque n’est plus suffisant, et que certains utilisateurs ont maintenant besoin d’une solution de chiffrement native dans leur base de données.
L’orateur explique alors la démarche de recension des besoins des utilisateurs pour aboutir à une solution. Un des besoins identifiés est d’utiliser une solution open-source, et dont le code, à terme, est présent dans PostgreSQL.
Les solutions déjà existantes ne correspondant pas, Percona développe alors une réponse aux besoins, avec comme objectif l’intégration dans PostgreSQL.
Ça n’est pas le cas actuellement : Percona propose une version modifiée de PostgreSQL et une extension : pg_tde. Deux patchs proposés, mais pas encore intégrés sont en effet nécessaires pour proposer un chiffrement des tables.
La solution est donc open-source, et utilisable, dans des limites connues, et l’objectif de l’intégration dans PostgreSQL reste à atteindre.
À la suite de la présentation précédente, l’orateur Zsolt Parragi détaille l’implémentation actuelle de pg_tde : quel chemin pour y arriver, qu’est-ce qui fonctionne, que reste-t-il à faire ?
L’orateur Kaarel Moppel présente les différentes approches possibles pour analyser les logs d’une instance PostgreSQL : d’outils Unix comme sed/awk, en passant par pgBadger jusqu’au chargement des logs dans une table de PostgreSQL, les possibilités sont nombreuses.
L’orateur présente un nouvel outil : pgweasel, écrit en GO, permettant d’extraire des informations agrégées des fichiers de logs, en visant de meilleures performances que les outils existants. Une réécriture en Rust permet d’ailleurs d’être encore plus rapide qu’en GO.
Les orateurs Giulio Calacoci et Martín Marqués reviennent sur l’histoire de l’outil Barman, connu et utilisé depuis des années par de nombreux utilisateurs pour mettre en œuvre leurs stratégies de sauvegardes et restaurations des instances PostgreSQL.
Si l’activité de l’outil, sous-entendu, son développement, a été chaotique ces dernières années, il a été décidé de relancer, à travers une communauté d’utilisateurs, la vie de l’outil pour répondre aux besoins actuels.
L’orateur Dirk Krautschick explique le fonctionnement et l’utilisation du couple Kafka/Debezium pour « consommer » les flux de données d’une instance PostgreSQL.
Debezium est le connecteur utilisé par Kafka pour consommer les données issues du décodage logique des journaux de transactions d’une instance PostgreSQL. Cela permet de concevoir des architectures de données évitant de devoir copier des données ou requêter une base : tous les changements de données sont envoyés dans le flux.
L’orateur mentionne pour finir un nouvel outil : Apache Flink, conçu très récemment !
Les orateurs Álvaro Herrera et Antonin Houska détaillent un besoin
très présent pour les administrateurs de bases de données : devoir
réorganiser physiquement une table. Après un historique des
différentes solutions présentes dans PostgreSQL (VACUUM FULL), les
orateurs expliquent la difficulté d’intégrer l’outil
pg_squeeze dans
PostgreSQL, ce second outil faisant la même chose que la première
commande, mais en minimisant le verrouillage de l’objet traité.
En effet, les orateurs proposent le renommage de VACUUM FULL et
l’intégration de pg_squeeze dans une commande REPACK et son option
CONCURRENTLY. Le patch est en cours d’intégration et a besoin de
testeurs !
L’oratrice Teresa Lopes expose un certain nombre de bonnes pratiques à intégrer lorsque l’on s’attaque à des bases dépassant les 100TB.
Parmi les pistes évoquées, Teresa détaille les opérations de VACUUM,
les sauvegardes, et la réorganisation des colonnes en fonction de leur
type.
Les orateurs Maximilian Stefanac et Philipp Thun présentent Cloud Foundry, PaaS utilisé par SAP Business Technology, et reposant sur PostgreSQL.
L’orateur Aivars Kalvāns explique ce qu’on peut retirer comme information d’un plan d’exécution PostgreSQL.
L’orateur Josef Machytka revient sur les cas de corruption qu’il a eu à traiter.
Il présente un outil qu’il a écrit pour générer des crashs de bases de données de manière à étudier les solutions envisageables pour corriger les problèmes.
High availibility
L’orateur Stefan Fercot évoque l’intégration de deux outils complémentaires : Patroni pour la haute disponibilité et pgBackRest pour les sauvegardes et restauration des instances PostgreSQL.
Quelles sont les différentes étapes où Patroni utilise pgBackRest : archivage, réinitialisation d’un nœud, bootstrap du cluster. On comprend que pgBackRest intervient aux moments critiques de la gestion des données de PostgreSQL.
Un point important noté par Stefan : pour savoir si tout se passe bien, il est essentiel de lire les logs des trois composants impliqués !
L’orateur Alastair Turner explique les points importants à savoir lorsqu’on souhaite utiliser PostgreSQL dans un cluster Kubernetes.
Quels sont les composants et concepts utilisés : réseau, stockage, automatisation…
L’oratrice Polina Bungina revient sur ce qu’implique le décodage logique dans PostgreSQL, au regard de son expérience chez Zalando. En effet, cette technologie est loin d’être simple et peut entrainer des effets de bords désastreux pour une instance de production.
De la définition d’un LSN (Log Sequence Number) à la description d’un slot et des différentes informations qui le constitue, on comprend au fur et à mesure les différents points critiques qui peuvent entrainer de vraies difficultés en cas de problèmes.
En effet, une simple commande de maintenance sur une table répliquée
peut entrainer le stockage d’un gros volume de données, en plus des
WALs habituels, à cause du réordonnancement des transactions
répliquées. Il faut alors surveiller la vue pg_stat_replication_slots.
L’orateur Cameron Murdoch souhaite ajouter quelques points importants qu’on ne lit pas dans les blogposts habituels sur Patroni, notamment la nécessité de sécuriser les flux vers les différents composants d’un cluster.
Création d’utilisateurs dédiés, de certificats pour des flux sécurisés, procédures de mises à jour des différents composants : autant de points critiques qui doivent faire partie de l’intégration de Patroni, et le plus tôt possible pour éviter d’avoir à corriger plus tard.
Autres
L’oratrice Claire Giordano fait le bilan des nombreuses contributions nécessaire à fabriquer PostgreSQL 18 : le code, bien sûr, mais pas seulement : la documentation, les évènements communautaires, les contributions financières : de nombreux acteurs s’associent pour former une communauté riche et diverse !
L’oratrice Priyanka Chatterjee évoque un aspect mal connu : la gestion des vulnérabilités dans le projet PostgreSQL. Qu’est-ce qu’un CVE, comment le projet PostgreSQL est organisé pour répondre, et qu’est-ce qu’un utilisateur doit comprendre des informations publiées lors de la publication d’un correctif de sécurité.
L’orateur Joaquim Oliveira, détaille les difficultés rencontrées par l’agence spatiale européenne (ESA) suite au rachat de VMware par Broadcom, et le passage en produit commercial fermé de Greenplum.
L’agence a étudié différentes solutions pour rester dans un monde moins fermé. La décision a finalement été prise de travailler avec la solution Warehouse de EDB.
Bonne nouvelle, WarehousePG sur lequel est basée l’offre d’EDB est open source.
Conclusion
À nouveau, cette conférence a apporté aux quelques centaines de présents de la matière pour l’avenir, en plus des nombreuses rencontres et discussions : la communauté PostgreSQL est plus riche et diverse que jamais !
