De retour du FOSDEM PGDay 2026

Le 30 janvier 2026 s’est déroulé le FOSDEM PGDay, un événement annuel entièrement dédié à PostgreSQL, organisé à Bruxelles en amont du FOSDEM. Cette conférence marque le début de la saison des conférences PostgreSQL en Europe.

L’édition 2026 nous a offert un programme varié, couvrant à la fois les mises à jour majeures sans interruption de service, l’optimisation des performances et l’analyse statistique avancée. Les sessions ont également exploré en profondeur le fonctionnement interne de l’exécuteur, les mécanismes de détection et de correction des corruptions, ainsi que de nombreux retours d’expérience sur la performance sur Kubernetes et bien entendu du vibe coding au-dessus de PostgreSQL managé dans le cloud.

Zero-Downtime Upgrades: PostgreSQL and OS/glibc at Global Scale

Alexander Sosna

Ce retour d’expérience de GitLab décrit une stratégie d’upgrade PostgreSQL réellement sans interruption à très grande échelle (40–60 To, multi-zones), où seule la réplication logique s’est révélée viable. Le pilotage repose sur l’Apdex afin de mesurer l’impact utilisateur réel des opérations. L’architecture combine pg_upgrade sur un nœud cible, resynchronisation logique et possibilité de rollback. Un point critique concerne les upgrades OS/glibc et les collations, traitées via une gestion fine et progressive des index, entièrement automatisée.

Efficiently approximating/estimating percentiles and histograms

Tomas Vondra Le calcul des percentiles et quantiles est une opération analytique courante, mais coûteuse lorsqu’il est exact. Cette présentation montre comment y répondre à l’aide de méthodes d’approximation, en s’appuyant notamment sur les extensions tdigest et ddsketch. Tomas y expose les principes sous-jacents à ces types de données et leur utilisation pratique, en particulier pour produire des histogrammes offrant une représentation lisible des distributions.

Storage Performance Matters: Benchmarking PostgreSQL on Kubernetes

Jonathan Battiato

L’exécution de PostgreSQL sur Kubernetes impose des choix de stockage déterminants pour les performances et la fiabilité, CloudNativePG fournissant un cadre de gestion natif, mais volontairement agnostique du stockage. Cette présentation analyse l’impact des comportements internes de PostgreSQL (WAL, buffers, scans séquentiels) sur les performances d’E/S. Elle compare les volumes locaux et les volumes réseau afin d’en mesurer les effets sur les charges de travail. Des retours terrain et des benchmarks (FIO, pgbench) permettent d’identifier les goulets d’étranglement et d’optimiser les plateformes Data sur Kubernetes. Une initiative de containers est, à ce titre, en cours de développement afin de permettre d’automatiser la caractérisation des stockages envisagés pour stocker les données des bases.

Lighting talks

Après la pause déjeuner, c’est le temps du Lighting talks. Les orateurs ont 5 min pour parler d’un sujet autour de PostgreSQL.

Les sujets abordés :

• LISTEN / NOTIFY Présenté comme une file sérialisée avec table interne et advisory locks. Très utile, mais peut devenir un hotspot.
• One Database to Rule Them All Mise en perspective des bases se disant « compatibles PostgreSQL » via pgscorecard.
• RPM Packaging Devrim explique les contraintes réelles du packaging PostgreSQL.
• AI Code & PostgreSQL Retour d’expérience critique sur les PR générées par IA.

Batching in Executor

Amit Langote

Cette conférence, très technique, a mis en lumière les limites historiques de l’exécuteur de PostgreSQL, toujours basé sur un traitement tuple par tuple. Malgré des optimisations récentes, ce modèle reste coûteux sur les CPU modernes, notamment pour les workloads analytiques. Amit nous présente un prototype introduisant un traitement par lots de tuples au sein de l’exécuteur. L’idée est de tirer partie à la fois des capacités SIMD des processeurs et de mieux gérer la localité des données dans le cache processeur. Celui-ci repose sur une nouvelle API, une abstraction de batch et des extensions des Table AM. Les premiers résultats sont prometteurs et ouvrent la voie à un exécuteur PostgreSQL plus efficace et orienté batch. Le principe proposé par Amit est de permettre de détecter au plus tôt les cas où les données sont adjacentes en mémoire (SeqScan, par exemple) et de basculer sur le mode Batch dans ces cas. Cela permet de faire coexister à la fois les traitements OLTP standards et ce nouveau mode batch (qui a pour vocation d’adresser les trafics OLAP).

From Crisis to Control: Detect and Fix Corruptions

Derk van Veen

Un sujet redouté de tous les DBA : la corruption de données dans PostgreSQL. Derk partage son retour d’expérience concret sur des corruptions réelles, parfois anciennes, pour lesquelles une restauration depuis les sauvegardes n’était pas toujours possible. La présentation détaille tout le processus, depuis la détection de la corruption et le déblocage du vacuum jusqu’aux choix techniques permettant de limiter l’impact et corriger le problème. Cette présentation a mis en évidence la nécessité d’une compréhension fine du fonctionnement interne de PostgreSQL et l’usage combiné de plusieurs extensions spécialisées. Une session très pédagogique, qui donne de véritables clés pour affronter les corruptions avec méthode et confiance, et éviter la perte de données.

Pour plus de détails, il a écrit un article sur le sujet “Database corruption in PostgreSQL”.

Vibe-coding with Postgres: really?

Matt Cornillon

Cette présentation de fin de journée était rafraîchissante : comment faire évoluer une application web python en utilisant PostgreSQL avec des agents IA pour réaliser l’implémentation de nouvelles fonctionnalités utilisant des “embeddings”. Matt nous a montré comment, à l’aide de plusieurs agents (un pour le code, un pour la base) et Gemini, il a pu implémenter une fonctionnalité étendue de recherche sur un site web fictif de vente de fleurs. Outre l’agent générant le code python, nous avons pu voir comment l’agent PostgreSQL utilisé dans ce projet a repris le schéma pour le transformer. Cela passe par l’analyse de l’existant par l’agent et la proposition d’implémentation (que le développeur peut modifier) avant que les agents effectuent les modifications réellement.

Conclusion :

Le FOSDEM PGDay 2026 confirme son positionnement de conférence technique, orientée production réelle et évolution du moteur PostgreSQL. Pour un consultant PostgreSQL, c’est un événement à forte valeur ajoutée.