Les langages d’interrogation des graphes

Dans l’article précédent, nous avons terminé par l’observation que les bases de données graphiques existent sous de nombreuses formes, qu’elles diffèrent dans leur façon de stocker les graphes et les modèles de données supportés. Elles diffèrent aussi sur la manière de les interroger.

Contrairement au monde relationnel, qui s’est convergé précocement vers SQL et l’a conservé comme standard dominant pendant des décennies, l’écosystème des graphes a engendré une prolifération de langages:

• Cypher^[1], créé chez Neo4j, représente les motifs en ASCII art:
  (a:Person)-[:KNOWS]->(b:Person) ;
• Gremlin^[2], issu d’Apache TinkerPop, est impératif et basé sur des étapes:
  g.V().hasLabel('Person').out('KNOWS') ;
• PGQL^[3], d’Oracle, intègre les motifs de graphe dans une enveloppe de type SQL ;
• Et en 2024, GQL^[4] a été ratifié comme norme ISO/IEC 39075, le premier nouveau langage de requête de base de données à atteindre une standardisation ISO depuis SQL lui-même.

Pour cette série, le plus pertinent est SQL/PGQ^[5], standardisé dans SQL:2023. C’est une extension de SQL qui permet de définir des graphes à propriétés sur des tables existantes et de les interroger avec une syntaxe de motifs de type GQL/PGQL intégrée dans un SELECT standard.

À quel point SQL est-il bon pour les graphes ?

Prenons un réseau social stocké dans deux tables: person et knows.
Une requête Cypher qui cherche les amis d’amis ressemble à:

 MATCH (a:Person)-[:KNOWS]->(b)-[:KNOWS]->(c)
 WHERE a.name = 'Alice'
RETURN c.name

L’équivalent en SQL pur est une double jointure croisée:

SELECT DISTINCT c.name
  FROM person a
  JOIN knows k1 ON k1.src = a.id
  JOIN person b ON k1.dst = b.id
  JOIN knows k2 ON k2.src = b.id
  JOIN person c ON k2.dst = c.id
 WHERE a.name = 'Alice';

Ce n’est pas mal. C’est verbeux, mais c’est expressible, le JOIN est explicite, et que ce soient deux sauts ou dix, chaque saut est conciste à écrire d’avantage de JOINs.

Essayons quelque chose de plus centré sur les graphes maintenant. Supposons que nous voulons toutes les personnes atteignables depuis Alice en cinq sauts KNOWS. En SQL/PGQ (très similaire à Cypher), c’est un seul motif:

SELECT c.name
  FROM GRAPH_TABLE(
          social_graph
    MATCH (a IS Person WHERE a.name = 'Alice')-[IS KNOWS]->{1,5}(c IS Person)
  COLUMNS (c.name)
) AS g;

En SQL, cela devient un peu lourd:

WITH RECURSIVE reachable(id, depth, path) AS (
    SELECT p.id
         , 0
         , ARRAY[p.id]
      FROM person p
     WHERE p.name = 'Alice'
    UNION ALL
    SELECT k.dst
         , r.depth + 1
         , r.path || k.dst
      FROM reachable r
      JOIN knows k ON k.src = r.id
     WHERE r.depth < 5
       AND k.dst <> ALL(r.path)
)
SELECT DISTINCT p.name
  FROM reachable r
  JOIN person p ON p.id = r.id
 WHERE r.depth > 0;

L’auteur encode désormais la limite de profondeur, transporte le chemin dans un tableau pour éviter les cycles, et retire la ligne racine à la fin. PostgreSQL 14 a ajouté les clauses SEARCH et CYCLE^[6] qui masquent une partie de cette gestion administrative, mais la requête reste un calcul de point fixe récursif qui arrive à produire le bon résultat.

Bien que ce soit un parcours de graphe basique, les choses deviennent encore plus complexes. Pour les plus courts chemins, il faudrait suivre la distance et faire du “pruning”. Si on demande un tracé (pas de répétition d’arêtes), il faudrait suivre les arêtes, pas seulement les sommets.

Définir et interroger un graphe en SQL/PGQ

À partir d’ici, nous utilisons un exemple plus riche, situé dans la galaxie Star Wars. Les Jedi combattaient sur des planètes, et les Sith sur des stations. Les tables de sommets sont jedi, sith, planet et station, chacune avec un id et un name, plus un title pour les combattants et une region pour les lieux. Deux tables d’arêtes, fought_on_planet et fought_on_station, contiennent chacune un identifiant source, un identifiant destination, et le nom de la bataille.

CREATE TABLE jedi (
    id     BIGINT PRIMARY KEY,
    name   TEXT,
    title  TEXT
);

CREATE TABLE sith (
    id     BIGINT PRIMARY KEY,
    name   TEXT,
    title  TEXT
);

CREATE TABLE planet (
    id      BIGINT PRIMARY KEY,
    name    TEXT,
    region  TEXT
);

CREATE TABLE station (
    id      BIGINT PRIMARY KEY,
    name    TEXT,
    region  TEXT
);

CREATE TABLE fought_on_planet (
    a       BIGINT REFERENCES jedi (id),
    b       BIGINT REFERENCES planet (id),
    battle  TEXT,
    PRIMARY KEY (a, b)
);

CREATE TABLE fought_on_station (
    a       BIGINT REFERENCES sith (id),
    b       BIGINT REFERENCES station (id),
    battle  TEXT,
    PRIMARY KEY (a, b)
);

Le graphe est déclaré sur celles-ci:

CREATE PROPERTY GRAPH galaxy
    VERTEX TABLES (
        jedi    KEY (id) LABEL force_user PROPERTIES (id, name, title),
        sith    KEY (id) LABEL force_user PROPERTIES (id, name, title),
        planet  KEY (id) LABEL place      PROPERTIES (id, name, region),
        station KEY (id) LABEL place      PROPERTIES (id, name, region)
    )
    EDGE TABLES (
        fought_on_planet
            SOURCE KEY (a)      REFERENCES jedi (id)
            DESTINATION KEY (b) REFERENCES planet (id)
            LABEL fought_at     PROPERTIES (battle),
        fought_on_station
            SOURCE KEY (a)      REFERENCES sith (id)
            DESTINATION KEY (b) REFERENCES station (id)
            LABEL fought_at     PROPERTIES (battle)
    );

Les labels regroupent des tables: force_user couvre deux tables de sommets, place en couvre deux, et fought_at couvre les deux tables d’arêtes. Le graphe ne contient aucune donnée.
Dans PostgreSQL, c’est un nouveau type de relation (RELKIND_PROPGRAPH) qui vit dans pg_class sans “heap” (table) et sans colonne propre, ce qui fait qu’il se comporte comme une vue. Cinq nouveaux catalogues (pg_propgraph_element, pg_propgraph_label et trois autres) enregistrent ses éléments, labels et propriétés.

L’interroger:

SELECT *
FROM GRAPH_TABLE (
            galaxy
      MATCH (a IS force_user)-[IS fought_at]->(b IS place)
    COLUMNS (a.name AS fighter, b.name AS battlefield, b.region)
);

Comment fonctionne la réécriture ?

PostgreSQL n’a pas de nouveau nœud “exécuteur”. L’analyseur transforme GRAPH_TABLE en un nouveau type de “range-table”, RTE_GRAPH_TABLE. La réécriture, le même stade qui étend les vues, la remplace ensuite par une sous-requête ordinaire.
Il procède en quatre étapes:

1. Le motif est lu de gauche à droite dans une liste de motifs d’éléments: sommets, arêtes dans les deux sens, et sous-motifs imbriqués.
2. Chaque nom de variable unique devient un facteur de chemin. Une variable qui apparaît deux fois, dans un cycle qui retourne à a, partage un même facteur, et ses prédicats sont conjoints par AND.
3. Chaque expression de label est résolue vers les tables qu’elle couvre, donnant un élément de chemin par table.
4. Chaque combinaison d’éléments le long du chemin est énumérée par un DFS (recherche en profondeur d’abord) récursif. Une combinaison n’est valide que si les clés source et destination de chaque table d’arêtes relient vraiment les deux tables de sommets voisines. Chaque combinaison valide devient un JOIN entre les tables d’arêtes et de sommets sur ces clés, et toutes sont combinées par UNION ALL.

Dans notre requête, force_user a deux tables, fought_at en a deux, et place en a deux, il y a donc 2 × 2 × 2 = 8 combinaisons. Seulement deux sont valides: un Jedi sur une planète, et un Sith dans une station. La requête devient équivalente à:

SELECT jedi.name, planet.name, planet.region
  FROM jedi, fought_on_planet, planet
 WHERE jedi.id = fought_on_planet.a
   AND planet.id = fought_on_planet.b
UNION ALL
SELECT sith.name, station.name, station.region
  FROM sith, fought_on_station, station
 WHERE sith.id = fought_on_station.a
   AND station.id = fought_on_station.b;

À partir de ce point, le planificateur et l’exécuteur voient des jointures et une union, rien de spécifique aux graphes. Ceci a une certaine valeur car nous bénéficions des index, des statistiques, de l’interrogation parallèle et de tout ce que PostgreSQL possède — ce qui rappelle l’argument que nous faisons dans le précédent article de la série sur les bases de données graphes construites sur des systèmes matures.

Il y a ici une subtilité qui compte pour la lecture de tout benchmark comparant les deux formalismes.

Dans un motif de longueur fixe, SQL/PGQ est obligé de toucher les tables de sommets. Le motif lie les sommets, donc la jointure vers la table de sommets fait partie de la sémantique même lorsqu’aucune propriété de sommet n’est demandée, car il n’y a pas de clés étrangères (FK). Si vous modélisiez le même graphe vous-même en SQL pur et aviez seulement besoin de la traversée des arêtes, à condition d’avoir défini des FK, joindre les tables d’arêtes seules suffit.

Note: il y a un effort récent, non validé, de la part de hackers PostgreSQL pour éliminer les inner joins basés sur les clés étrangères, ce qui serait bénéfique pour la réécriture SQL/PGQ + FK sur les tables élémentaires du graphe^[7].

Ce qui est supporté et ce qui ne l’est pas

La norme recense 100 fonctionnalités. L’implémentation validée en couvrait 26. Elle supporte les motifs graphiques avec WHERE, les motifs de sommets, les motifs d’arêtes sous forme complète et abrégée, la disjonction de labels (label1|label2), les références de propriétés, GRAPH_TABLE, le DDL incluant ALTER et DROP, plusieurs labels par table élémentaire, et les vues comme tables élémentaires.

Les plus intéressantes des 74 manquantes relèvent (pour la plupart) de cinq mécanismes que la norme définit au-dessus d’un motif de base:

PostgreSQL n’est pas seul ici. Le SQL/PGQ d’Oracle est tout aussi réduit, DuckPGQ n’ajoute que ANY SHORTEST, et l’ancien PGQL d’Oracle supporte la plupart de ces fonctionnalités.

L’annulation (“git revert”)

SQL/PGQ a été validé le 16 mars 2026 pour PostgreSQL 19. Début septembre, une discussion sur pgsql-hackers concernant certains problèmes dans sa représentation/catalogue et ses dépendances d’objets s’est achevé par une décision de le retirer.
Les reviewers ont estimé qu’il devait être retiré de cette version afin que les problèmes puissent être corrigés proprement pour 20, sans la pression de la compatibilité ascendante.

La fonctionnalité devrait revenir dans une version future. La réécriture elle-même n’est pas la partie en cours de refonte, elle devrait donc survivre, inchangée, ce qui signifie que le travail supplémentaire — VLE (variable length edge), motifs multi-chemins, etc. — pourra s’appuyer sur le même socle.

Il est d’ailleurs à noter que tout cela n’a pas à être nécessairement dans le noyau. PostgreSQL n’a pas de parser hook, donc une extension ne peut pas ajouter de grammaire, et les parser hooks ont été proposés et discutés à maintes reprises sans aboutir. La dernière mention concernait la manière de publier SQL/PGQ comme fonctionnalité expérimentale^[8].
Il ne reste à SQL/PGQ que deux options: travailler dans le noyau, ou faire ce que fait Apache AGE et parser une chaîne à l’exécution ; bien sûr, la deuxième est un élément pour une extension, pas pour une fonctionnalité du noyau.
Si les extensions avaient pu étendre le parseur, cela aurait pu être construit et prouvé hors de l’arbre, puis ensuite considéré pour un module contrib ou pour le noyau. Ce n’est pas un argument en faveur des parser hooks. C’est une observation sur là où le coût de ne pas les avoir finit par peser.

La fonctionnalité que tout le monde réclame

Des morceaux manquants, l’un domine chaque conversation sur les requêtes de graphe: les arêtes de longueur variable (VLE).
C’est la fonctionnalité que les utilisatrices et utilisateurs de graphes réclament en premier, et c’est souvent la raison pour laquelle on se tourne vers un langage de requête de graphe plutôt que d’écrire des jointures. La difficulté est proportionnelle à l’échelle. Un motif borné sur deux ou trois sauts peut être fait avec une réécriture similaire vers des jointures. Un motif pouvant atteindre des centaines de sauts, ou s’exécuter de manière non bornée jusqu’à épuisement du graphe, est un problème différent avec ses propres exigences de mémoire, de terminaison et de gestion des cycles.

La norme rend cela plus difficile qu’il n’y paraît, car elle définit plusieurs mécanismes et fonctionnalités qui interagissent avec elle. Comment le motif s’étend, quels chemins comptent comme admissibles, et lesquels de ceux-ci sont retournés sont décidés indépendamment, et chaque combinaison implique une stratégie d’exécution différente. Tous les chemins sur une profondeur bornée, un seul chemin le plus court, et les extrémités atteignables distinctes sont des motifs différents dont il faut tenir compte dans la conception. Bien sûr, on NE peut PAS tout supporter, mais il est important de garder ces sémantiques en tête.

Les implémentations varient. Une approche est une nouvelle réécriture, cette fois vers des CTE récursifs, s’appuyant sur les clauses SEARCH et CYCLE et faisant beaucoup de gestion administrative directement dans la requête pour les différentes sémantiques. En bout de ligne, c’est un BFS (recherche en largeur) basé sur des ensembles exprimé sous forme de jointures ; c’est acceptable mais ce ne sera ni performant ni flexible à combiner avec d’autres fonctionnalités comme les variables de chemin.

Une autre approche étend chaque longueur possible dans son propre UNION ALL, ce qui ne peut pas gérer le cas non borné. C’est une très mauvaise idée ; Oracle fait ça. Puis il y a les stratégies au niveau de l’exécuteur: DFS avec état de chemin pour le backtracking, ou BFS exécuté directement dans l’exécuteur (tous avec de nouveaux nœuds exécuteur). Chacune est adaptée à un objectif différent, qu’il s’agisse d’accessibilité, de plus court chemin, ou d’énumération de tous les chemins possibles. L’implémentation future prendra en compte toutes celles-ci, autrement on ne peut pas considérer Postgres dans la course, en aucune manière.

Points clés

SQL/PGQ réécrit les motifs de graphe en jointures — pas de nouveaux nœuds exécuteur, pas de moteur de graphe. Le planificateur gère le reste avec les index, les statistiques et l’interrogation parallèle.

L’implémentation validée couvrait 26 des 100 fonctionnalités de la norme, de quoi prouver l’approche mais en s’arrêtant avant les problèmes difficiles. Les quantificateurs, les modes de chemin et les arêtes de longueur variable étaient intentionnellement différés.

L’annulation est lié au “timing”. Les catalogues et le suivi des dépendances nécessitent une base plus propre pour PostgreSQL 20. Le moteur de réécriture lui-même n’est pas en cours de refonte.

La gestion des arêtes de longueur variable est la fonctionnalité requise. La norme définit plusieurs mécanismes au-dessus du VLE qui impliquent différentes stratégies d’exécution — BFS basé sur des ensembles via des CTE récursives, bras UNION ALL par longueur, ou DFS/BFS au niveau de l’exécuteur avec de nouveaux nœuds. Chacune sert un objectif différent.

Sans parser hooks, SQL/PGQ doit vivre dans le noyau ou utiliser un analyseur de chaîne à l’exécution.

Et maintenant ?

Le prochain article examine les autres options de graphes dans PostgreSQL: Apache AGE, pgRouting, et le cas pratique pour ou contre chacune.
Ensuite, un benchmark comparant SQL/PGQ à Apache AGE.
Et enfin, à quoi ressemble la vision à long terme pour les requêtes de graphe dans PostgreSQL, et pourquoi la trajectoire pointe vers l’absorption des charges de travail des graphes dans les systèmes relationnels.

Qu’est-ce qu’un graphe ?

Un graphe est un ensemble d’éléments et un ensemble de connexions entre ces éléments. La définition est simple!
Les éléments sont appelés sommets (ou nœuds) et les connexions sont appelées arêtes (ou relations).

Formellement, un graphe $G $ est modélisé comme un couple $(V, E)$, où $V $ est un ensemble de sommets et $e $ est un sous-ensemble du produit cartésien de $V $ par lui-même, représentant un ensemble d’arêtes :
$E \subseteq V \times V$

On distingue trois types de graphes : orientés, non orientés et pondérés.

1. Pour un graphe orienté, une arête $e $ est le couple ordonné $(u, v)$ dans $e $, où $u $ est le sommet source et $V $ est le sommet destination; un exemple est l’abonnement sur Twitter, où la relation a une direction spécifique :
   arête $e = (u, v) \in E$

2. Pour un graphe non orienté, une arête $e $ est un couple non ordonné contenant $u $ et $V $ dans $e $ ; un exemple est l’amitié sur Facebook, où la relation est mutuelle :
   arête $e = { u, v } \in E$

3. Un graphe pondéré étend cette structure en un triplet $(V, E, w)$, où $w$ est une fonction qui associe à chaque arête dans $e $ un nombre réel (un poids), utile pour représenter des distances, des coûts ou des forces :
   triplet $(V, E, w)$ où $w: E \to \mathbb{R}$

Où sont les graphes ?

La puissance du modèle graphe réside dans son universalité. Dès qu’on commence à chercher, les graphes sont partout.

• Les réseaux sociaux représentent l’amitié, les abonnements et les interactions comme des arêtes connectant des sommets utilisateurs.
  Savoir si Alice connaît Bob par l’intermédiaire d’autres personnes
  est essentiellement un parcours du graphe pour trouver cette relation.

• Les systèmes de détection de fraude modélisent les transactions bancaires entre comptes sous forme de graphes. Les activités frauduleuses génèrent des structures particulières très faciles à repérer telles des cycles ou des amas denses de relations transactions-comptes.
  Les relations entre entités révèlent souvent la fraude plus fiablement que les entités elles-mêmes.

• Les chaînes d’approvisionnement et la logistique utilisent les graphes pour modéliser les dépendances entre fournisseurs, entrepôts et expéditions.

• Les biologistes représentent les réseaux d’interaction protéique et les relations médicament-cible.
  

• Les réseaux informatiques utilisent les graphes pour représenter les topologies.

• Le Web est un autre exemple de graphe.
  Les pages sont des sommets, les hyperliens sont des arêtes orientées, et le graphe résultant est l’une des structures les plus vastes et les plus étudiées en informatique :

Modéliser comme un graphe

Ce que partagent les exemples de domaines ci-dessus sont des propriétés qui font du graphe une solution intuitive pour nous, êtres humains. Les relations sont aussi importantes que les entités elles-mêmes.
Le schéma est souvent irrégulier ou évolutif. Les requêtes suivent fréquemment des chaînes de connexions dont la longueur ou la forme n’est pas connue à l’avance.

Les graphes sont également efficaces parce qu’ils sont faciles à raisonner visuellement. Les êtres humains comprennent mieux les choses avec des exemples, et un graphe rend les relations explicites. Cette clarté visuelle et structurelle se traduit souvent par des modèles de données et des algorithmes plus faciles à expliquer et à questionner.

Le modèle défini au début de cet article, un ensemble de sommets et un ensemble d’arêtes sans donnée attachée, sous-tend une grande partie de la théorie classique des graphes et constitue la base des frameworks de traitement de graphes et des systèmes de gestion de bases de données graphe. Il est toutefois trop limité pour la plupart des scénarios de bases de données réels, car il ne transporte aucune information au-delà de la structure. Les modèles plus riches utilisés dans les bases de données graphe sont construits sur cette base.

• Le Labeled Property Graph (LPG) est le modèle conceptuel standard utilisé par la plupart des systèmes de bases de données graphe. Il enrichit le graphe simple par deux mécanismes : les labels, qui classent les sommets et les arêtes en types, et les propriétés, qui attachent des données arbitraires de type clé-valeur aux sommets et aux arêtes individuels.
  Un sommet pourrait avoir le label Person et les propriétés name='Alice' et age=21.
  Une arête pourrait avoir le label KNOWS et la propriété since = "09.08.2007".

D’autres variantes du LPG sont implémentées par d’autres systèmes avec de légères extensions ou restrictions ; par exemple, Neo4j prend en charge un nombre arbitraire de labels par sommet mais limite les arêtes à exactement un label.

• Le Resource Description Framework (RDF) adopte une approche différente. Le RDF représente l’information comme des collections de triplets sujet, prédicat, objet $(s, p, o)$.
  Si les systèmes basés sur le RDF constituent une part significative du paysage des bases de données graphe, ils suivent un modèle de données différent du LPG et sont hors du cadre de cette série. Nous le mentionnons uniquement pour le contexte, cette série d’articles étant centrée sur les bases de données graphe de type “labeled property graph”.

Les nombreuses formes des bases de données graphe

Le paysage des bases de données graphe est hétérogène. Les systèmes diffèrent fondamentalement dans la manière dont ils stockent les graphes, les modèles de données qu’ils supportent et les langages de requête qu’ils exposent.

Les bases de données graphe natives sont conçues de A à Z autour du modèle graphe. Leurs schémas de stockage et leurs moteurs de requête sont pensés avec les schémas d’accès aux graphes comme préoccupation principale : elles visent à « suivre les pointeurs », ou à accéder à l’adjacence directement, de sorte que la navigation « ne devienne pas un JOIN ».
Neo4j en est l’exemple le plus marquant. Pendant longtemps, son moteur de stockage utilisait des enregistrements de taille fixe avec des pointeurs directs entre eux, et c’était essentiellement ainsi que les gens décrivaient le stockage graphe natif.
Après une quinzaine d’années, en 2024, Neo4j a introduit un format de blocs qui co-localise les données apparentées dans des blocs de longueur variable à l’intérieur de pages ^[1]. Bien que cette prise de conscience tardive soit un progrès, elle implique que la description « natif équivaut à suivre des pointeurs » n’est plus tout à fait exacte.
La définition utile devrait donc être comportementale, c’est-à-dire que les systèmes natifs tentent de rendre l’accès à l’adjacence direct, que ce soit par des pointeurs, des blocs co-localisés ou d’autres schémas spécifiques aux graphes.

Les bases de données graphe non natives reprennent un backend mature existant ; une base relationnelle, orientée document ou clé-valeur, et construisent des capacités graphe par-dessus ^[2]. Les deux classes sont des bases de données graphe au sens où elles stockent, interrogent et gèrent des données de type graphe, mais leurs composants internes sont fondamentalement différents, ce qui implique que des optimisations spécifiques aux graphes sont disponibles, adapatées au backend.
En pratique, la différence porte davantage sur l’endroit où l’effort d’ingénierie est investi : par exemple, les systèmes non natifs héritent de décennies de travail en contrôle de concurrence, indexation, optimisation des requêtes et bien d’autres composants de SGBD.

Une étude d’une centaine de systèmes de bases de données graphe révèle qu’environ 66 % sont non natifs. La répartition des modèles de données sous-jacents se décompose comme suit : 34 % de stockage graphe natif, 24 % de bases de données relationnelles, 24 % de stockages clé-valeur ou à colonnes larges, et 18 % de stockages orientés document. Cela a du sens : on souhaite rendre un SGBD existant capable de supporter les requêtes graphe si possible, offrant ainsi aux utilisateurs la meilleure interface possible.

C’est précisément à cet endroit que PostgreSQL entre en jeu. En tant que base de données relationnelle mature, elle représente une part massive de cet écosystème non natif à travers des extensions et de nouvelles normes SQL.

Points clés

Avant de passer à l’implémentation technique, rappelons les concepts fondamentaux de cette introduction :

• Les graphes sont universels : Au fond, ils ne sont que des sommets (nœuds) et des arêtes (relations), ce qui les rend idéaux pour des données complexes et interconnectées comme les réseaux sociaux ou les réseaux de fraude.
• Le LPG est la norme de l’industrie : Le modèle Labeled Property Graph étend les graphes simples en permettant d’attacher des labels et des propriétés clé-valeur aux nœuds et aux arêtes.
• Natif vs. non-natif est une distinction comportementale : Les bases de données natives (comme Neo4j) optimisent l’accès direct à l’adjacence, tandis que les bases non natives exploitent des moteurs de niveau entreprise existants (relationnels, orientés document) pour traiter les charges de travail graphe.
• Le paysage est hybride : Plus de 66 % des solutions de bases de données graphe sont construites sur des backends non graphe, prouvant qu’il n’est pas toujours nécessaire de déployer une nouvelle base de données native pour interroger des structures de type graphe.

Et maintenant ?

Maintenant que nous avons posé le vocabulaire de base, nous pouvons explorer comment intégrer ce modèle dans le monde relationnel. Dans la partie 1, nous plongerons directement dans SQL/PGQ dans PostgreSQL : ce que cette nouvelle norme apporte, comment elle est implémentée en interne, et les limitations actuelles.

C’est aussi le moteur préféré de notre équipe pour traduire à la fois le SQL étranger et les applications étrangères pour PostgreSQL ! Nous croyons en les transitions, pas les migrations — un déplacement progressif de l’ancien moteur de base de données vers le nouveau, spécifiquement pour réduire les risques et optimiser les résultats. Utiliser un projet comme celui-ci fait toute la différence pour atteindre ces deux objectifs.

La dernière version majeure est sortie il y a un peu de temps, mais nous sommes toujours enthousiastes quant à ce qui est nouveau et nous avons tenu à le partager.

Nouveautés

La version 5.0 (notes de version) est sortie le 25 novembre 2025 et une version mineure a déjà été publiée depuis (notes de version 5.1) le 18 décembre 2025. Ces éditions du projet sont le résultat direct des efforts massifs de l’équipe IvorySQL pour fournir de nombreuses améliorations de qualité ainsi que pour implémenter la compatibilité avec PostgreSQL 18.

IvorySQL 5 a apporté de nombreux changements nécessaires, notamment :

• PLiSQL — un sous-ensemble compatible d’Oracle PL/SQL
• Support des paquets compatibles Oracle
• Support des séquences style Oracle
• les améliorations de v5.0 telles que ROWID, %TYPE, %ROWTYPE et les sous-fonctions imbriquées

En particulier, nous apprécions beaucoup les améliorations fonctionnelles.

Par exemple, IvorySQL dispose désormais d’un meilleur traitement des valeurs NULL, où NULL est désormais traité comme une chaîne vide en mode compatible (correspondant au comportement Oracle) pour éviter des bugs lors de la migration. Ainsi, dans des situations telles que SELECT CONCAT('a' || NULL), IvorySQL retournera désormais 'a' au lieu de suivre le comportement de PostgreSQL qui retournerait NULL.

Une amélioration que nous apprécions particulièrement est qu’il est désormais possible d’imbriquer des fonctions et des procédures. Les fonctions peuvent être intégrées dans d’autres fonctions (à la manière des paquets Oracle, mais plus simplement, en utilisant uniquement des méthodes privées). Cela permet d’organiser une logique complexe en un seul endroit.

Dans le même ordre d’idées, le support a également été ajouté pour DO [ LANGUAGE lang_name ] code [USING IN | OUT | IN OUT, ...].

L’essayer

Actuellement, nous intégrons des applications allant de quelques paquets, procédures et fonctions (environ 10 à 50 objets) à des chargements de données massifs incluant environ 50 000 objets (plus de 10 000 procédures et des centaines de paquets).

Bien que de nombreuses fonctionnalités devront encore être ajoutées avec le temps, cela réduit considérablement l’effort nécessaire pour achever avec succès la transition d’Oracle vers PostgreSQL.

Si vous envisagez de le tester vous-même, il existe une pléthore d’options pour commencer (y compris la compilation depuis la source, l’utilisation de conteneurs, etc.)… et même une compilation WASM ! En particulier, cela permet d’exécuter IvorySQL directement dans le navigateur sans avoir à l’installer localement ; c’est très pratique pour examiner le support de syntaxe et faire le premier pas vers le monde de PostgreSQL.

Vous pouvez déployer le projet IvorySQL-WASM localement en quelques étapes, en suivant le billet de blog publié par IvorySQL sur le sujet.

Sinon, vous pouvez essayer le WASM hébergé sur le site web d’IvorySQL.

Et la suite ?

Vous souhaitez en apprendre davantage sur l’utilisation d’IvorySQL ? Restez à l’affût des webinaires enregistrés sur leur site web (à venir !), ou consultez les enregistrements de la conférence HOW2025 à Jinan, en Chine, en attendant.

La prochaine conférence à Jinan est déjà prévue, du 26 au 28 avril ! (Au passage, l’appel à contributions est ouvert jusqu’au 27 février 2026.)

Notre équipe est heureuse d’employer des contributeurs au projet IvorySQL. Certains de nos membres (Cédric Villemain, Yasir Hussain Shah) ont été reconnus dans les notes de version de 5.0 et 5.1 — et nous avons d’autres ajouts prévus. Pour la prochaine version, nous avons prévu des développements passionnants, notamment :

• la syntaxe de contrainte ENABLE/DISABLE
• l’ajout du paquet UTL_FILE
• le corps de CREATE TRIGGER style Oracle (sans avoir besoin de créer une fonction au préalable)
• le support de l’opérateur de jointure legacy d’Oracle (+)

Nous avons hâte de voir les résultats du travail communautaire en cours pour la prochaine version. De nombreuses fonctionnalités excellentes sont activement ajoutées ; par exemple, récemment, un nouveau contributeur au projet, Rophy Tsai, a ajouté les paquets DBMS_OUTPUT et DBMS_UTILITY : des éléments largement utilisés dans les bases de code SQL basées sur Oracle. Ils ont récemment été fusionnés dans la branche principale d’IvorySQL et seront probablement inclus dans la prochaine version mineure ou majeure.

Pour ceux qui souhaitent passer à PostgreSQL ou l’explorer sans modifications importantes de leur logique de base de données et de leurs applications existantes, IvorySQL (en particulier v5.x) offre une solution pratique. Une migration directe vers PostgreSQL pourrait, dans certains cas, nécessiter des changements importants tant au niveau des objets de base de données qu’au niveau du code applicatif. IvorySQL aide à combler cet écart, permettant une adoption plus fluide de PostgreSQL avec une plus grande compatibilité.

Ressources complémentaires

• Annonce PostgreSQL.org pour IvorySQL 5
• Feuille de route d’IvorySQL 5.0 sur GitHub

Cet événement fait partie d’une succession d’évènements climatiques exceptionnels et de records battus aux États-Unis, en Europe et en Asie ces dernières années. La semaine dernière encore, au moment de la rédaction de cet article, l’État de Washington (États-Unis) a connu des inondations historiques qui ont causé des dégâts considérables : plus de 11 millards de m³ d’eau se sont déversés sur l’État en dix jours. Ces pluies torrentielles devraient se poursuivre sur toute la côte ouest américaine jusqu’à la fin de l’année.

J’ignore si ce contexte a influencé la réception de mon intervention lors de la conférence, et je suis reconnaissante qu’elle ait non seulement été entendue, mais aussi écoutée, et même qu’elle ait suscité des réflexions et des discussions. Je dois avouer que je ne m’y attendais pas.

Je fais partie de ceux qui pensent que les défis environnementaux sont sur le point de transformer radicalement nos sociétés à tous les niveaux et à l’échelle planétaire, à mesure que les ressources se raréfient et se redistribuent. Je me demande si d’autres se posent la même question : « À quoi bon un salaire confortable si les pommes de terre ne poussent plus ? » Maslow a clairement démontré qu’il est moins important d’être riche que de se nourrir. Pourtant, comme nous le savons, l’environnement n’est toujours pas une priorité absolue, malgré tout ce que nous voyons arriver.

Il me semblait donc logique d’aborder ce sujet lors d’une conférence PostgreSQL, car il devrait être discuté partout. Mais étais-je certaine de trouver un public réceptif ? Absolument pas !

Je me sentais un peu mal à l’aise – comme souvent lors de conférences vu mon manque de backgroud technique – à l’idée d’emmener le public sur un terrain qui n’était pas forcément celui qu’il recherchait. J’espérais ne pas ennuyer, déranger, ni même agacer. Mais dès les premières diapositives, j’ai vu que les gens prenaient des photos des données que je présentais, certains acquiesçaient, d’autres découvraient ces chiffres pour la première fois et haussaient un sourcil. Et quand j’ai fait le lien avec nos activités quotidiennes et l’impact de la pollution numérique que nous produisons, au lieu de susciter l’indifférence ou la désapprobation, j’ai eu droit à des regards intéressés, du genre « pourquoi pas ! ».

Alors quelle pollution numérique produisons-nous ?

Selon Greenpeace, la pollution numérique désigne toutes les formes de pollution causées par le secteur informatique : émissions de gaz à effet de serre, contamination chimique, érosion de la biodiversité et production de déchets électroniques.

Oui, des solutions sont conçues pour que les data centers utilisent la chaleur qu’ils produisent afin de chauffer les bureaux ou les habitations avoisinantes, ce qui fonctionne en hiver. Des projets comme celui d’Amazon à Tallaght constituent « le premier réseau de chauffage urbain à grande échelle de ce type en Irlande », contribuant à « réduire considérablement les émissions dans la région de près de 1 500 tonnes de CO2/an, faisant de Tallaght un chef de file en matière d’action énergétique locale » (source).

Cependant, la croissance du nombre d’utilisateurs équipés d’au moins un terminal connecté (notamment dans les pays en développement), l’augmentation du ratio terminaux connectés/individu (de 2,1 en 2015 à 3,3 en 2020 en moyenne dans le monde), la hausse du trafic vidéo, conjuguée à la part croissante des images en HD et UHD, et le passage à la consommation à la demande (streaming, VOD, cloud gaming) ont entraîné une explosion du trafic sur les réseaux (plus de 25 % par an) et dans les data centers (+35 % par an). Cette croissance est plus rapide que les gains d’efficacité énergétique des équipements, des réseaux et des centres de données. Ces prévisions de trafic sont d’ailleurs régulièrement revues à la hausse.

Bien que le nombre d’appareils « standard » (hors objets connectés) ait augmenté de manière significative entre 2000 et 2015, il se stabilise entre 2015 et 2025 car le marché est saturé.

Bien que la masse par utilisateur diminue légèrement, passant de 63 kg d’émissions de CO2 à 58 kg entre 2010 et 2025, la masse totale (équipements utilisateurs, réseaux, data centers) a été multipliée par plus de 2,5 en 15 ans : elle passe de 128 millions de tonnes en 2010 à 317 millions de tonnes en 2025.

Ceci explique la pression exercée sur les matières premières, notamment les « minerais de conflit » et autres terres rares.

La clé d’un monde plus vert

L’optimisation des performances des bases de données ne se limite pas à une amélioration des coûts et de la vitesse. En optimisant une requête, on économise l’énergie superflue utilisée pour les opérations de lecture/écriture et les déplacements inutiles sur le disque. D’autres pratiques responsables, qui permettent d’exploiter intelligemment la puissance de la technologie, contribuent non seulement à une meilleure efficacité technique, mais aussi, souvent inconsciemment, à la protection de l’environnement.

Par exemple, certaines actions que nous entreprenons régulièrement et qui ont également un impact positif sur notre planète incluent :

• l’optimisation des requêtes
• l’optimisation des index
• la réalisation d’audits de performance pour identifier les goulots d’étranglement et les problèmes
• le choix de technologies moins énergivores
• la réduction de l’empreinte des données (suppression des données redondantes, corrompues ou inutiles)
• l’optimisation de l’infrastructure de stockage et de la puissance de calcul afin de réduire la consommation d’énergie

Nous nous devons de considérer la sobriété numérique comme la clé de voute pour un code plus écologique et nous pouvons décider d’intégrer ce paramètre dans notre façon de travailler au quotidien et dans la façon dont nous concevons, gérons et développons des solutions de bases de données qui minimisent autant que possible notre empreinte environnementale.

Une remarque supplémentaire : l’IA, en particulier, entraîne une forte augmentation de la consommation d’eau, des émissions de CO2 et des déchets électroniques (l’entraînement des modèles d’IA est l’une des tâches les plus gourmandes en ressources au monde !). Dans un monde où l’IA est devenue omniprésente dans les applications et les pratiques de programmation quotidiennes, il est crucial d’utiliser ces technologies avec discernement afin de s’assurer qu’elles constituent réellement la meilleure solution au problème posé. L’IA est-elle vraiment la solution la plus appropriée au problème que vous avez en tête ? Ou envisagez-vous son utilisation simplement parce qu’elle est plus facile à mettre en œuvre qu’une solution plus complexe techniquement ?

C’est à Vous !

Je propose cette perspective sur nos tâches quotidiennes en espérant qu’elle soit intéressante. On se plaint parfois de ne pas trouver de sens à ce qu’on fait ; eh bien voilà !

Un petit message de notre équipe marketing Data Bene : Notre équipe d’ingénieurs PostgreSQL expérimentés peut vous aider à améliorer votre efficacité énergétique, à optimiser vos bases de données et à adopter des pratiques de codage responsables. Vous bénéficierez ainsi d’avantages directs : des opérations de base de données plus rapides, une consommation de ressources réduite, des coûts moindres et un impact environnemental moindre. Curieux d’en savoir plus sur nos services ? Contactez-nous ! Nous serions ravis d’en discuter.

L’événement

L’événement a duré 2 jours avec 90 exposants, 130 sessions, 150 intervenants et plus de 4 000 participants - une conférence de très grande envergure, située à la Cité des Sciences et de l’Industrie à Paris.

Ce lieu particulier était plus petit que celui de l’année dernière (Le Palais des Congrès) et les salles dans lesquelles nous sommes allés étaient toutes pleines en raison de leur petite taille (environ 20 ou 30 places tout au plus).

Le format des conférences

Les présentations ont été données en anglais et en français. Fait intéressant, il n’y avait pas de “salles silencieuses” cette année (où des écouteurs sont fournis à chaque participant). Tout le monde n’a pas apprécié ce format l’année dernière, mais c’était utile pour suivre deux conférences, ou basculer entre elles en fonction du contenu ou des questions.

Deux membres de notre équipe étaient présents et ont pu découvrir divers exposants et salles dédiées aux conférences répartis sur trois étages. Ces dernières duraient 20 minutes et bien que trop courtes pour entrer dans les détails, ce format était intéressant pour découvrir les nouvelles technologies et attiser notre curiosité d’un coup d’œil.

Le contenu des conférences

Il y avait six pistes dans lesquelles les conférences étaient catégorisées :

• Modèles économiques et gouvernance pour des stratégies ouvertes durables
• Intelligence artificielle et calcul scientifique pour l’analyse des données
• Architecture cloud et virtualisation pour un avenir autonome
• Développement - l’innovation logicielle en action
• Cybersécurité et chaîne de production logicielle : l’Open Source comme fondement de confiance
• Outils collaboratifs et applications métier : reprendre l’autonomie numérique

Nous avons trouvé le sujet des solutions open source dans le secteur public le plus intéressant. En particulier, il était facile de voir que notre dépendance en tant que société mondiale aux cinq grandes entreprises technologiques (GAFAM : Google, Apple, Facebook, Amazon et Microsoft) a considérablement augmenté ces dernières années. Les logiciels open source sont une solution directe pour protéger notre droit collectif à la vie privée à l’ère numérique, ce qui explique exactement pourquoi des conférences comme celle-ci sont si importantes pour la découverte d’alternatives OSS et l’innovation qui conduit à un développement ultérieur dans ce secteur.

La participation

La fréquentation a été particulièrement importante dès le premier jour. Nous avons été ravis d’avoir l’occasion d’échanger en “présentiel”, et de rencontrer nos partenaires, en particulier OW2 qui organise également un évènement Open Source, annuel, en Juin. (L’appel à conférence est ouvert jusqu’au 14 février 2026 - consultez l’appel à propositions d’OW2Con’26 ici.)

L’évènement étant entièrement sur les technologies open source, nous avons pu discuter avec les nombreux participants de sujets tels que le support PostgreSQL, les difficultés et impacts organisationnel pour les entreprises souhaitant innover et adopter PostgreSQL, avec en trame de fond la demande du marché pour se libérer des contraintes de licence des éditeurs logiciels.

Nous avons également eu le plaisir de rencontrer des acteurs de l’innovation “hardware” open-source, en résonnance avec notre propre R&D sur les processeurs RISC-V.

De nombreux projets libres et open source étaient représentés. Quelques exemples incluent Nextcloud (une plateforme de collaboration cloud auto-hébergée que nous utilisons personnellement pour l’hébergement ici chez Data Bene), qui est une alternative à Nextcloud), et OpenTalk, une solution de visioconférence conforme au RGPD, opérant dans des centres de données allemands.

En conclusion

L’événement était réussi et bien organisé. La seule chose qui aurait amélioré l’expérience aurait été des présentations plus longues pour explorer les divers sujets abordés plus en profondeur. Si vous souhaitez découvrir de nouveaux projets open source, notez que l’événement est également une très bonne opportunité pour échanger en toute liberté sur ces sujets.

Les rediffusions vidéo pour 2025 n’ont pas encore été publiées, mais les enregistrements des conférences passées peuvent être trouvés sur le site officiel, ici.

Dans l’ensemble, nous avons beaucoup apprécié l’événement et espérons y assister l’année prochaine !

C’était la première fois que l’équipe Data Bene assistait à cet événement, et nous sommes heureux de partager qu’il s’est avéré très positif.

La conférence

Lieu et lieu de l’événement

Comme son nom l’indique, cette conférence a lieu sur l’île méditerranéenne d’Ibiza. Pour ceux qui le connaissent moins, le site touristique officiel propose un bon aperçu auquel vous pouvez vous référer. Et il va sans dire que ce site classé au patrimoine mondial de l’UNESCO offre des attractions incroyables en dehors même de la conférence. Combiné à un potentiel long trajet en avion, il est fortement recommandé de prévoir un jour ou deux supplémentaires (ou plus) pour explorer l’île et profiter de l’expérience locale.

L’événement lui-même est hébergé au Palacio de Congresos de Ibiza ; un centre de congrès sur deux niveaux avec de multiples salles et un service de restauration. Bien qu’il soit situé en dehors de la capitale, le lieu est accessible en voiture en un temps raisonnable (~15 minutes). À noter également que le centre est à distance de marche de nombreux hôtels, restaurants et d’une plage ! Nous avons séjourné à l’Hôtel Tres Torres, que nous pouvons recommander, bien que, pour être honnête, il soit difficile de faire un mauvais choix, surtout après un peu de recherche préalable.

En bref, pour ce qui est des activités annexes, notre recommandation principale serait de visiter la ville d’Ibiza. Vous y trouverez une quantité surprenante de commerces, de restaurants et de visites. Ajoutez à cela une promenade dans le quartier historique et vous avez une expérience plutôt mémorable.

Participation

PGIBZ de cette année a accueilli environ 30 à 40 participants venus du monde entier, dont la Chine et les États-Unis. Et bien qu’il y ait certes deux côtés à la pièce, je considère cette taille de groupe plutôt comme un point positif. En effet, lors des sessions de questions-réponses après les présentations, ainsi que lors des pauses café, j’ai trouvé les interactions globalement plus engageantes. C’était particulièrement vrai lors des rencontres et retrouvailles avec des membres d’entreprises de petite taille ainsi que des entreprises de dimension globale.

Présentations de notre équipe

Catherine

La première des intervenantes Data Bene, et pour la présentation inaugurale de la première journée, était Catherine Bouxin. Sa présentation traitait de l’impact environnemental de la technologie et reflétait la philosophie selon laquelle les sujets importants ne sont pas toujours ceux dont on parle, et qu’ils ne sont souvent même pas considérés comme un problème ! En effet, Catherine a cadré cette conversation principalement comme un rappel de la responsabilité que nous partageons en tant que membres de la communauté PostgreSQL. De nombreuses inventions passionnantes ont vu le jour récemment, certaines avec des implications de transformation de la société, mais nous ne pouvons ignorer l’intensité des ressources que beaucoup d’entre elles nécessitent.

Nous souscrivons pleinement au message de Catherine sur la contribution à un avenir plus vert et la prise de décisions réfléchies à cette fin, et nous sommes ravis que cela ait été très bien accueilli par le public.

Cédric

Le deuxième jour, notre fondateur et PDG, Cédric Villemain, a présenté les points forts statistiques de la grande version 18 de PostgreSQL (notes officielles liées ici). (Après l’événement, il a créé un billet de blog sur le sujet des statistiques cumulées dans Postgres 18 — voir ici !) Notre équipe chez Data Bene est fan des statistiques et de la mise en évidence des données, ce qui nous a amenés à créer l’extension PostgreSQL StatsMgr. Si vous avez raté les informations sur StatsMgr et souhaitez en savoir plus, consultez notre précédent billet de blog et l’épisode de Postgres Café sur le sujet.

Evan

Immédiatement après Cédric, j’ai eu l’opportunité de présenter le développement et la maintenance d’une extension PostgreSQL basée sur Rust (encore au stade très précoce) qui aide à faciliter la transition d’Oracle vers PostgreSQL. Ce projet, nommé pgtap_gen, s’appuie sur le projet existant pgTAP pour automatiser la création de tests unitaires sur IvorySQL (un PostgreSQL forké à 100 % open source avec des composants analogues à Oracle). J’ai trouvé très encourageant de recevoir les réactions et retours du public. De plus, c’est gratifiant de participer à l’écosystème PostgreSQL, même pour des initiatives de preuve de concept !

Frédéric

Vers la fin du deuxième jour, Frédéric a prononcé un discours sur les niveaux d’isolation des transactions dans PostgreSQL (que vous aurez peut-être la chance de voir plus tard, car il a soumis la même présentation à pgDay Paris 2026 et PGDay CERN 2026 !). Il a exploré chaque niveau d’isolation de Postgres avec des exemples pratiques, et a expliqué comment tout fonctionne en coulisses pour définir des étapes concrètes permettant de choisir en toute confiance le bon niveau pour le bon contexte. Les participants ont semblé trouver la présentation intéressante et instructive, nous pourrions donc voir d’autres contenus sur ce sujet et des sujets similaires pour aider ceux qui ont raté l’opportunité d’apprendre sur ce thème.

Conclusions

Nous avons choisi de sponsoriser et d’assister à PGIBZ 2025 car nous croyons qu’il est important de promouvoir la communauté PostgreSQL dans le monde. Quoi qu’il en soit, c’est un événement qui cherche à améliorer l’éducation autour de Postgres. Les bénéfices de l’événement sont utilisés par l’organisation parente à but non lucratif, PostgreSQL España, pour financer la traduction de la documentation officielle PostgreSQL en espagnol.

Des approfondissements détaillés sur chacun des sujets de présentation mentionnés ci-dessus sont en cours ; n’hésitez pas à nous suivre sur LinkedIn et Mastodon pour les repérer quand ils seront publiés sur notre blog.

Nous avons beaucoup apprécié notre temps passé à PGIBZ 2025, et sommes honorés d’avoir eu l’opportunité de présenter et de participer. Hâte de revenir l’année prochaine !

Références

• https://ibiza.travel/en/know-ibiza/where-we-are/
• https://pgibz.io/
• https://whc.unesco.org/en/list/417
• https://www.hoteltrestorresibiza.com/

Tout d’abord, la documentation

L’annexe K de la documentation PostgreSQL indique qu’une table peut contenir jusqu’à 1 600 colonnes.

Il s’agit d’une limite codée en dur, visible dans le code source à l’adresse src/include/access/htup_details.h :

#define MaxTupleAttributeNumber 1664
#define MaxHeapAttributeNumber	1600

Atteindre la limite de manière classique

Vérifions d’abord cette affirmation par quelques tests.

Jouer avec la définition de la table

Nous utilisons ici un script bash simple, facile à adapter aux différents tests.

-- Exemple classique

DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tint_1601;';
    EXECUTE 'CREATE TABLE tint_1601(i_1 int);';
    FOR i IN 2..1601 LOOP
        EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);
    END LOOP;
END $$;

Le résultat est le suivant :

NOTICE:  table "tint_1600" does not exist, skipping
ERROR:  tables can have at most 1600 columns
CONTEXT:  SQL statement "ALTER TABLE tint_1600 ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTE

Jusqu’ici, tout va bien (ou du moins, tout fonctionne comme prévu).

Vous pourriez tenter de remplacer le type int4 par le type int2 pour arriver à créer une table de plus de 1 600 colonnes. Mais cela ne fonctionnera pas plus, car il s’agit d’une limite codée en dur.

Jouer avec le contenu d’une table

Générons une table de 1600 colonnes à partir du script sql précédent :

DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
    EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
    FOR i IN 2..1600 LOOP
        EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);
    END LOOP;
END $$;

Construisons puis insérons un tuple de 1600 colonnes :

DO $$
DECLARE
    s TEXT;
    rows_inserted int;
BEGIN
    s := format(
                 'INSERT INTO tint_1600 VALUES (1%s);'
               , repeat( ',1' , 1599 )
               );
    EXECUTE s;

    GET DIAGNOSTICS rows_inserted = ROW_COUNT;
    RAISE NOTICE 'Rows inserted: %', rows_inserted;
END $$;

The output is:

NOTICE:  Rows inserted: 1
DO

Sans surprise, c’est encore un succès.

Trop gros pour échouer ?

Continuons à repousser les limites.

On créé maintenant une autre table de 1 600 colonnes, cette fois avec le type de données char(127).

On réutilise notre script bash avec quelques modifications :

-- Create a table with 1,600 columns: 1 x int + 1599 x char(127)
DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
    EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
    FOR i IN 2..1600 LOOP
        EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);
    END LOOP;
END $$;

-- Insert a tuple - 1 x int + 1599 x char(127)
DO $$
DECLARE
    s TEXT;
BEGIN
    s := format(
                 'INSERT INTO tint_1600 VALUES (1%s);'
               , repeat( $q$,'1'::char(127)$q$ , 1599 )
               );
    EXECUTE s;
END $$;```

Le résultat est :

ERROR: row is too big: size 25616, maximum size 8160

Comme on peut le voir, la table comporte effectivement 1 600 colonnes, mais cette fois, le tuple ne peut pas tenir dans une seule page heap, ce qui explique l'erreur « row is too big: size 25616, maximum size 8160 ». Si vous avez fait attention au script, vous avez pu constater que les colonnes sont définies comme `NOT NULL`. Aussi, lors de la création de la table, PostgreSQL aurait pu se rendre compte que l'insertion de données serait impossible. Mais il n'y a pas eu d'alerte.

## Quid des JOINs ?

Pour simplifier, testons avec une jointure automatique :

```sql
SELECT a.*,b.* FROM tint_1600 a, tint_1600 b;
ERROR:  target lists can have at most 1664 entries

Maintenant, c’est la clause SELECT de (a.*,b.*) qui a atteint sa propre limite (MaxTupleAttributeNumber = 1664).

Atteindre la limite de colonnes de manière inattendue

Il arrive que vous deviez modifier votre application, et que cela entraîne des modifications de schéma.
La plupart du temps, il s’agit de modifications de tables, comme l’ajout ou la suppression de colonnes.

Explorer ADD / DROP COLUMN

Voyons ce qui se passe côté SQL lorsque nous ajoutons, puis supprimons, une colonne.

=# CREATE TABLE tadc_1600(i_1 int NOT NULL);

CREATE TABLE

=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;

ALTER TABLE

=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
   FROM pg_attribute
   WHERE attrelid=(
                   SELECT oid
                   FROM pg_class
                   WHERE relname='tadc_1600'
                   )
     AND attnum > 0 ORDER BY attnum;

 attname | attnum | attstorage | attnotnull | attisdropped
---------+--------+------------+------------+--------------
 i_1     |      1 | p          | t          | f
 i_2     |      2 | p          | t          | f
(2 rows)

=# ALTER TABLE tadc_1600 DROP COLUMN i_2;

ALTER TABLE

=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
   FROM pg_attribute
   WHERE attrelid=(
                   SELECT oid
                   FROM pg_class
                   WHERE relname='tadc_1600'
                   )
     AND attnum > 0 ORDER BY attnum;

           attname            | attnum | attstorage | attnotnull | attisdropped
------------------------------+--------+------------+------------+--------------
 i_1                          |      1 | p          | t          | f
 ........pg.dropped.2........ |      2 | p          | f          | t
(2 rows)

Lors de la suppression d’une colonne, cette colonne

• est renommée en « . » + « pg.dropped.» + attnum + « . »,
• devient NULLable,
• est marquée comme supprimée.

Itérer sur l’ajout/la suppression de colonnes

On peut se demander s’il existe une limite au nombre d’opérations d’ajout/suppression qui peuvent être exécutées sur une table donnée.

Comme d’habitude, testons :

-- ADD / DROP COLUMN example
DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tadc;';
    EXECUTE 'CREATE TABLE tadc(i_1 int);';
    FOR i IN 2..1601 LOOP
        EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);
        EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);
    END LOOP;
END $$;

Le résultat est :

ERROR:  tables can have at most 1600 columns
CONTEXT:  SQL statement "ALTER TABLE tadc ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTE

Oh oh ! On a atteint la limite des 1 600 ici aussi !

Explorons un peu ce qui se passe :

=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
   FROM pg_attribute
   WHERE attrelid=(
                   SELECT oid
                   FROM pg_class
                   WHERE relname='tadc'
                   )
     AND attnum > 0 ORDER BY attnum;

             attname             | attnum | attstorage | attnotnull | attisdropped
---------------------------------+--------+------------+------------+--------------
 i_1                             |      1 | p          | t          | f
 ........pg.dropped.2........    |      2 | p          | f          | t
 ........pg.dropped.3........    |      3 | p          | f          | t
 ........pg.dropped.4........    |      4 | p          | f          | t
 ........pg.dropped.5........    |      5 | p          | f          | t

 ........pg.dropped.1599........ |   1599 | p          | f          | t
 ........pg.dropped.1600........ |   1600 | p          | f          | t
(1600 rows)

La table tadc comporte 1 600 colonnes. Vous pouvez vous en apercevoir car toutes les modifications sont ajoutées à la table, et son contenu n’est pas réécrit.

Aussi, à ce stade, toute modification supplémentaire visant à ajouter ou supprimer des colonnes sera vouée à l’échec.

Comment faire pour me sortir de cette situation ?

Le chevalier du VACUUM devrait sauver la princesse PostgreSQL, non ?

Et non ! La commande VACUUM fonctionne au niveau du tuple, donc même si vous exécutez un VACUUM FULL, la structure de la table ne changera pas.

Donc le dragon a mangé le chevalier, que fait-on ?

Il ne s’agit pas d’un problème de tuples morts, mais plutôt d’un problème de catalogue.
Vous devez créer une nouvelle définition de table.

Voici quelques solutions, des plus simples aux plus complexes :

1. Créer une nouvelle table avec interruption de service

   • CREATE TABLE LIKE (INCLUDING ALL)
   • Copier (COPY) les données de l’ancienne table vers la nouvelle
   • Renommer les tables
   • Supprimer l’ancienne table

2. Exploiter la réplication logique pour minimiser les interruptions de service

   • CREATE TABLE LIKE (INCLUDING ALL)
   • CREATE local PUBLICATION/SUBSCRIPTION
   • Une fois les données synchronisées, arrêter/mettre en pause le service applicatif
   • Supprimer l’abonnement
   • Renommer les tables
   • Redémarrer/relancer l’application
   • Supprimer l’ancienne table

Contactez-nous

Vous avez d’autres idées pour résoudre ce problème ? Vous avez trouvé d’autres moyens étranges de déclencher cette erreur liée à la limite codée en dur ? Contactez-nous ! Nous sommes toujours ravis d’échanger sur PostgreSQL.

Le programme comptait 101 conférences techniques animées par 105 intervenants. La majorité des sessions étaient en mandarin, avec un track anglophone proposé en traduction simultanée. Vous pouvez consulter le programme complet sur IvorySQL.io et retrouver les replays sur Weibo via ce lien.

Nous étions un petit groupe de la communauté internationale présents, dont Grant Zhou qui assure entre autre la liaison et la collaboration avec l’association PostgreSQL en Chine et dans le reste du monde.

Sur le plan technique, le contenu était dense et particulièrement intéressant. J’ai retenu notamment :

• La présentation d’Alena Rybakina sur le planificateur de requêtes PostgreSQL et les stratégies pour contourner certaines limites.

• Un focus clair et concret sur Patroni (Haute-Disponibilité) par Alexander Kukushkin et Polina Bungina.

• Florentz Tselai a présenté 2 sujets en appliquant ses préceptes: simplicité efficacité, sur l’utilisation de «l’IA» avec PostgreSQL et la gestion des données avec comme support Sun Tzu et les 36 stratagèmes.

• Également une très bonne introduction à Bazel et son utilisation pour Monogres (à découvrir bientôt) présenté avec énergie par Alvaro Hernandez.

  Monogres est une initiative très intéressante qui doit permettre de renforcer le contrôle de la supply chain logicielle, un thème majeur dans l’IT de nos jours. Et j’y ai aussi vu une très belle occasion d’offrir une vitrine a des variations de PostgreSQL avec des fonctionnalités et des correctifs dont l’inclusion dans PostgreSQL lui-même même ou le backport dans des version majeures précédentes n’est pas toujours possible.

• Michael Meskes avait l’honneur d’une conférence plénière pour un sujet qui le mérite largement: « From Code to Commerce: Open Source Business Models Today », une keynote sur l’open-source et les logiciels libres, appliqués à l’écosystème PostgreSQL.

• Mon collègue Andrea a présenté les évolutions et les tendances des entreprises pour transiter vers IvorySQL et PostgreSQL

• Pour ma part, j’ai présenté linux PSI dans le contexte PostgreSQL.

Comme tout est en streaming, je vous encourage à aller explorer et visionner les sujets qui vous intéressent. Il y a ausi des conférences en anglais pré-enregistrées mais j’avoue avoir profité des créneaux pour échanger avec des participants.

En apparté des conférences, j’ai eu la chance de rencontrer plusieurs membres de la communauté PostgreSQL chinoise très réputés pour leur implication dans le succès de PostgreSQL localement. J’ai eu aussi l’occasion d’en apprendre d’avantage sur Cloudberry, en remplacement de Greenplum, merci Dianjin Wang!

Pour Data Bene s’était également un moment prévu pour rencontrer l’équipe en charge d’IvorySQL, basée en grande partie dans le Shandong, la province où se trouve Jinan, ville hôte des conférences. Ivory est un projet auquel nous participons activement et qui permet aux entreprises de s’affranchir d’Oracle «en douceur». C’est un sujet important pour nos clients et qui occupe un place prépondérante dans notre partenariat avec Highgo: ils portent ce projet depuis plusieurs années déjà et nous voulons permettre aux entreprises européenes d’en profiter avec un accompagnement et expertise adaptée.

Les conférences étaient très bien organisées et l’acceuil formidable, le «Social Event» au «beer garden» local parfaitement adapté à la chaleur de Jinan fin juin!

Vu le programme des conférences j’ai amèrement regreté de ne rien comprendre (Il y avait 1 track en Anglais et 5 en Mandarin) … mais il se dit déjà que l’an prochain les conférences en Mandarin pourraient peut être être traduites (en anglais), et la date avancée en Mai pour profiter d’un climat plus doux.

Il y a tellement à y apprendre que j’y retournerai avec grand plaisir.

La conférence de cette année s’est centrée sur les thèmes de l’IA, du DevOps et des technologies cloud-native, de l’engagement de la communauté open source, de la sécurité et de la conformité, des systèmes et de l’infrastructure, ainsi que du FOSS @ home (explorer le monde des applications auto-hébergées et des services cloud).

La conférence a attiré des participants venus du monde entier pour tout discuter autour de l’open source, le Linux au cœur bien sûr, tout en poursuivant la discussion sur des sujets tels que les systèmes embarqués et l’IoT. Comme toujours, un mélange unique de discussions technologiques de pointe et de résolution pratique de problèmes dans chaque espace est ce qui rend SCaLE spécial.

Conduire les éléphants : PostgreSQL@SCaLE22x

PostgreSQL@SCaLE22x s’est déroulé comme un événement dédié de deux jours et deux sessions, les 6 et 7 mars 2025, reconnu dans le cadre des directives des événements communautaires du PostgreSQL Global Development Group. L’équipe de sélection comprenait Gabrielle Roth, Joe Conway et Mark Wong, garantissant la qualité qu’on attend de la communauté PostgreSQL.

La liste des intervenants était impressionnante : Magnus Hagander, Christophe Pettus, Peter Farkas, Devrim Gündüz, Hamid Akhtar, Henrietta Dombrovskaya, Shaun Thomas, Gülçin Yıldırım Jelínek & Andrew Farries, Nick Meyer et Jimmy Angelakos. Une session particulièrement mémorable s’intitulait “Row-Level Security Sucks. Can We Make It Usable ?” — une prise de position honnête et rafraîchissante sur la fonctionnalité RLS de PostgreSQL qui a probablement résonné auprès de plus d’un administrateur de base de données dans le public.

Le panel communautaire “Posez-nous vos questions” a été animé par Stacey Haysler et a compté Christophe Pettus, Devrim Gündüz, Jimmy Angelakos, Magnus Hagander et Mark Wong. C’est lors de ces sessions que le véritable transfert de connaissances a lieu — pas de discours marketing, juste des praticiens discutant entre pairs des mécanismes internes de PostgreSQL, des performances, des bonnes pratiques et de l’avenir de la base de données.

Dans les coulisses, les bénévoles Derya Gumustel, Erika Miller, Hamid Akhtar, Jennifer Scheuerell, Mark Wong et Roberto Mello ont tout fait fonctionner sans accroc, PGUS ayant assuré le stand dans le hall d’exposition.

Personnellement, j’ai eu le plaisir de collaborer avec Jimmy Angelakos lors de ses sessions de streaming en direct avec d’autres invités comme Henrietta Dombrovskaya, Mark Wong, Gülçin Yıldırım Jelínek, et même une brève apparition de Devrim Gündüz.

L’un des sujets discutés avec Gülçin Yıldırım Jelínek dans le podcast est de savoir s’il y a un intérêt communautaire pour poursuivre Postgres Café. Qu’en pensez-vous ? Souhaitez-vous voir plus d’épisodes de cette série de podcast, élargissant les discussions sur les extensions et le développement open source au reste de la communauté et au-delà ? Dites-le nous : contact@data-bene.io

Quelque chose pour tout le monde

Il y a beaucoup d’événements colocalisés en plus de PostgreSQL @ SCaLE, dont “SCaLE : The Next Generation (TNG)”, un événement technologique axé sur la jeunesse encourageant des activités interactives et des présentations pour les étudiants, ainsi que le concours annuel Cybersecurity Capture the Flag (CTF) présenté par Cal Poly FAST et Pacific Hackers.

SCaLE reste un excellent endroit pour réseauter en vue d’avancer dans sa carrière dans l’open source. Se mêler aux stands est toujours un excellent moyen de faire des connexions et de trouver des opportunités, bien sûr, mais la journée Open Source Career Day est également revenue afin d’offrir un espace dédié aux professionnels et aux technologistes en herbe pour qu’ils puissent puiser dans des ressources, des outils, des exemples concrets et un contenu engageant issus des présentations et des ateliers.

L’amusante tradition de tenir une soirée jeux le samedi avec nourriture et boissons s’est également poursuivie cette année, avec un Trivia Night (présenté par Uncoded) et d’autres activités amusantes comme le lancer de hache gonflable, la cible Nerf, les arts et l’artisanat, une salle de jeux de société, une soirée casino et une salle de blocs pour construire des “derby cars” , jouer au pictionary ou construire avec de gros blocs.

Gardez votre calendrier libre pour SCaLE 23x

SCaLE s’est imposé comme une présence constante à Pasadena, et cette stabilité a permis à la conférence de bâtir des relations durables avec la communauté locale et les lieux. Restez à l’affût des annonces de SCaLE 23x — la visite promet d’en valoir la peine.

Pour ceux qui s’intéressent plus spécifiquement à PostgreSQL@SCaLE, restez attentifs aux listes de diffusion PostgreSQL pour les annonces concernant les opportunités de bénévolat, d’intervention ou d’autres moyens de participer à l’événement de l’année prochaine. Le parcours et le stand PostgreSQL sont une source constante de discussions engageantes parmi ceux de la communauté Postgres et au-delà, reflétant l’adoption croissante de la base de données dans l’industrie.

Le rassemblement open source pour tous

Dans un monde où de nombreuses conférences technologiques ressemblent davantage à des vitrines élaborées pour vendeurs, SCaLE reste ce rassemblement rare où la communauté passe en premier, la collaboration est authentique, et les discussions technologiques sont portées par des praticiens qui résolvent de vrais problèmes. Notez bien SCaLE 23x dans votre calendrier — c’est une conférence qui tient toujours sa promesse de rassembler les enthousiastes de l’open source pour collaborer et apprendre réellement.

Vous regrettez de ne pas y avoir été ? Vous pouvez toujours consulter la playlist YouTube des interventions qui ont été enregistrées lors de la conférence, pour bénéficier au moins du savoir qu’elles contiennent.

Épisode 6 : Développement d’extensions PostgreSQL, la communauté et au-delà

À quelle fréquence les entreprises expriment-elles leur intérêt pour une contribution open source ? Il est évident que toute aide apportée profite directement aux projets open source. Mais y a-t-il des avantages pour l’entreprise qui contribue ? Quels sont les modes de contribution qu’une entreprise peut envisager ? Ce sont des questions que nous entendons souvent. Explorons donc certaines des réponses évoquées dans cet épisode à travers un bref récapitulatif.

Contribuer aux projets et aux communautés open source

Chez Data Bene, nous avons déjà quelques clients intéressés par le développement de fonctionnalités ou d’améliorations pour l’écosystème PostgreSQL.

Ces entreprises souhaitent corriger des bugs et ajouter de nouvelles fonctionnalités qui complètent leurs cas d’utilisation et leurs piles technologiques dans PostgreSQL, Citus Data et les technologies associées pour accomplir deux choses :

1. Pour créer les fonctionnalités dont ils ont besoin, qui sont nativement intégrées au logiciel en amont et maintenues de manière transparente par la grande communauté open source, et
2. Pour garantir que d’autres personnes ayant un cas d’utilisation similaire puissent également tirer parti de ces avantages.

Les temps changent ; la seule façon pour le logiciel source de rester pertinent, utile et bénéfique pour le public mondial qui l’utilise est de bénéficier de contributions mondiales, garantissant qu’il répond toujours aux besoins réels des utilisateurs d’année en année.

Pourquoi soutenir des projets open source ?

La dépendance vis-à-vis des fournisseurs est un problème majeur dans le secteur des logiciels et des services ; contribuer aux projets open source garantit que la technologie ouvertement développée peut continuer à l’être. L’utilisation de la technologie FOSS signifie que vous évitez d’investir dans une entreprise qui pourrait fermer le code ou en restreindre l’accès, donnant ainsi à l’utilisateur final la liberté de continuer à utiliser et à développer des outils essentiels qui font partie de sa pile technologique.

Ce type de logiciel est également soumis à un processus de développement très visible, ce qui signifie qu’il est beaucoup plus difficile d’intégrer dans le code sous-jacent des atteintes à la vie privée, des vulnérabilités de cybersécurité, etc.

De plus, les logiciels open source sont créés par des individus du monde entier ayant des perspectives et des parcours variés ; cela garantit qu’ils sont minutieusement testés, et intègrent un large éventail de fonctionnalités intégrées qui sont réellement utiles à de nombreux utilisateurs finaux. Cela permet à ce type de projets d’être couronnés de succès pendant de nombreuses années, aussi longtemps qu’il existe une communauté prête à les soutenir.

Exemple concret : PostgreSQL existe depuis plus de 35 ans de développement actif et figure toujours aujourd’hui en tête des enquêtes et des classements des développeurs comme étant la solution de base de données la plus appréciée, la plus utilisée et la plus populaire au monde !

Comment les entreprises peuvent-elles soutenir au mieux les projets open source ?

Il existe quelques moyens clés pour atteindre cet objectif final :

1. Incluez les contributions de code au temps de travail de vos ingénieurs. Lorsque vous allouez du temps aux développeurs pour travailler sur le code en amont, vous vous assurez que la technologie que vous exploitez (pour fournir un support et/ou des services, pour alimenter votre produit ou sur laquelle repose votre infrastructure) bénéficie de performances améliorées, de fonctionnalités étendues, de problèmes résolus ou de corrections de bugs.
2. Envisagez de développer des extensions. La création et la maintenance d’extensions permettent aux entreprises d’ajouter des fonctionnalités spécialisées ou de répondre à certains cas d’utilisation sans altérer la base de code principale. Dans le cas de PostgreSQL en particulier, cette extensibilité permet à Postgres de répondre aux besoins de différents secteurs, utilisateurs et entreprises, avec un écosystème polyvalent et solide. Ce type de système modulaire permet à PostgreSQL d’évoluer sans complexifier trop son noyau, ce qui rend le projet dans son ensemble plus facile à gérer et à mettre à jour.
3. Sponsorisez, organisez et participez à des événements. En tant qu’entreprise, vous pouvez choisir de promouvoir ou d’initier des conférences technologiques, des groupes d’utilisateurs, des ateliers et bien plus encore pour sensibiliser et éduquer le grand public sur la technologie que vous souhaitez voir prospérer. Les événements sont un excellent moyen pour les utilisateurs et les développeurs de collaborer, de discuter des avancées et de partager les meilleures pratiques, ce qui renforce la communauté et améliore le produit en conséquence.

Comment Data Bene contribue

Cédric Villemain, président de Data Bene, a développé pg_fincore et travaille actuellement sur StatsMgr, pg_psi et d’autres composants conçus pour améliorer les capacités statistiques de Postgres.

Notre équipe est également responsable d’un certain nombre de contributions dans le cadre de projets tels que Citus Data et Zammad.

Nous nous efforçons de sponsoriser, de présenter et de promouvoir des conférences et des groupes d’utilisateurs de la communauté PostgreSQL ou open source, tels que PostgreSQL Europe, pgDay Paris, AlpOSS, Capitole du Libre, et bien d’autres. Certains membres de notre équipe ont également initié ou font partie des comités d’organisation de divers événements tels que les groupes d’utilisateurs PostgreSQL de Barcelone et de Madrid et pgDay Lowlands. L’impact des événements sur le projet et la communauté dans son ensemble ne peut être sous-estimé, et il est important pour nous d’y contribuer de cette manière.

Enfin, nous aidons les clients à comprendre comment contribuer à PostgreSQL et à des projets open source similaires. Par le biais de formations, d’ateliers et de collaborations, nous les encourageons à apporter des contributions significatives qui correspondent à leurs objectifs et soutiennent la communauté dans son ensemble.

Si vous êtes un développeur souhaitant contribuer à l’écosystème open source et/ou PostgreSQL, ou aider les clients avec leurs besoins en R&D, notre équipe s’agrandit : rendez-nous visite sur notre site web pour voir les postes disponibles!

Regardez l’épisode complet

Vous souhaitez regarder la discussion dans son intégralité ? Elle est disponible sur YouTube (en anglais uniquement) :

Restez à l’écoute pour plus d’outils Postgres

A ce jour, nous avons terminé notre première série d’épisodes pour Postgres Café ! D’autres épisodes pourraient suivre, ou pas. Suivez-nous sur les réseaux sociaux (comme LinkedIn ou Mastodon) pour être informé des prochaines sorties. (Voulez-vous en savoir plus sur cette série de podcasts ? Faites-le nous savoir !)

Abonnez-vous à la playlist ou consultez-le pour des interviews sur les extensions open source comme StatsMgr pour une gestion efficace des statistiques de PostgreSQL, ou pgstream, un outil open source de capture de données modifiées (CDC) conçu spécifiquement pour PostgreSQL ou bien d’autres. PostgreSQL est l’une des bases de données les plus extensibles du marché avec un vaste écosystème d’extensions ; apprenez directement des experts en découvrant certaines des options disponibles.