{ "version": "https://jsonfeed.org/version/1.1", "title": "Data Bene - Tag: 'Planete PostgreSQL'", "language": "fr", "home_page_url": "https://www.data-bene.io/fr/", "feed_url": "https://www.data-bene.io/fr/blog/tag/planete-postgresql/feed.json", "description": "Base de données relationnelles, open-source et adaptives.", "items": [{ "id": "https://www.data-bene.io/fr/blog/postgresql-comme-bdd-graphe-part-1/", "url": "https://www.data-bene.io/fr/blog/postgresql-comme-bdd-graphe-part-1/", "title": "PostgreSQL comme base de données graphique, partie 1: SQL/PGQ dans PostgreSQL", "content_html": "\n

Cet article est le deuxième d’une série consacrée aux bases de données graphiques et à PostgreSQL. Le premier a posé les bases: qu’est-ce qu’un graphe, ce qu’on peut modéliser comme graphe, et le paysage des systèmes graphiques. Celui-ci passe du général au spécifique: comment on interroge les graphes, pourquoi SQL peut être maladroit pour cela, et ce que SQL/PGQ change. Il s’achève sur l’implémentation PostgreSQL, les raisons de son annulation, et quelques notes sur les fonctionnalités principales encore à venir.

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:

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)\n WHERE a.name = 'Alice'\nRETURN c.name

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

SELECT DISTINCT c.name\n  FROM person a\n  JOIN knows k1 ON k1.src = a.id\n  JOIN person b ON k1.dst = b.id\n  JOIN knows k2 ON k2.src = b.id\n  JOIN person c ON k2.dst = c.id\n 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\n  FROM GRAPH_TABLE(\n          social_graph\n    MATCH (a IS Person WHERE a.name = 'Alice')-[IS KNOWS]->{1,5}(c IS Person)\n  COLUMNS (c.name)\n) AS g;

En SQL, cela devient un peu lourd:

WITH RECURSIVE reachable(id, depth, path) AS (\n    SELECT p.id\n         , 0\n         , ARRAY[p.id]\n      FROM person p\n     WHERE p.name = 'Alice'\n    UNION ALL\n    SELECT k.dst\n         , r.depth + 1\n         , r.path || k.dst\n      FROM reachable r\n      JOIN knows k ON k.src = r.id\n     WHERE r.depth < 5\n       AND k.dst <> ALL(r.path)\n)\nSELECT DISTINCT p.name\n  FROM reachable r\n  JOIN person p ON p.id = r.id\n 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 (\n    id     BIGINT PRIMARY KEY,\n    name   TEXT,\n    title  TEXT\n);\n\nCREATE TABLE sith (\n    id     BIGINT PRIMARY KEY,\n    name   TEXT,\n    title  TEXT\n);\n\nCREATE TABLE planet (\n    id      BIGINT PRIMARY KEY,\n    name    TEXT,\n    region  TEXT\n);\n\nCREATE TABLE station (\n    id      BIGINT PRIMARY KEY,\n    name    TEXT,\n    region  TEXT\n);\n\nCREATE TABLE fought_on_planet (\n    a       BIGINT REFERENCES jedi (id),\n    b       BIGINT REFERENCES planet (id),\n    battle  TEXT,\n    PRIMARY KEY (a, b)\n);\n\nCREATE TABLE fought_on_station (\n    a       BIGINT REFERENCES sith (id),\n    b       BIGINT REFERENCES station (id),\n    battle  TEXT,\n    PRIMARY KEY (a, b)\n);

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

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

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 *\nFROM GRAPH_TABLE (\n            galaxy\n      MATCH (a IS force_user)-[IS fought_at]->(b IS place)\n    COLUMNS (a.name AS fighter, b.name AS battlefield, b.region)\n);

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\n  FROM jedi, fought_on_planet, planet\n WHERE jedi.id = fought_on_planet.a\n   AND planet.id = fought_on_planet.b\nUNION ALL\nSELECT sith.name, station.name, station.region\n  FROM sith, fought_on_station, station\n WHERE sith.id = fought_on_station.a\n   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:

MécanismeCe qu’il décidePostgreSQL
Quantificateurs: {n,m}, {n}, +, *Le nombre de sauts couverts par un motifNon supporté
Modes de chemin: WALK, TRAIL, SIMPLE, ACYCLICQuels chemins sont admissibles (quoi qui peut se répéter)Comporte comme WALK, mots-clés rejetés
Préfixes de recherche de chemin: ALL, ANY, ALL SHORTEST, SHORTEST nQuels chemins admissibles sont retournésSeulement ALL, le défaut
Modes de correspondance: REPEATABLE ELEMENTS, DIFFERENT EDGESSi les arêtes peuvent se lier deux foisSeulement REPEATABLE ELEMENTS
Plusieurs motifs de chemin séparés par des virgules dans un MATCHJointure de motifs sur des variables partagéesPatch existant, retardé après les quantificateurs

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.

  1. https://neo4j.com/docs/getting-started/cypher/ ↩︎

  2. https://tinkerpop.apache.org/gremlin.html ↩︎

  3. https://pgql-lang.org/ ↩︎

  4. https://www.iso.org/standard/76120.html ↩︎

  5. https://www.iso.org/standard/79473.html ↩︎

  6. https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-SEARCH ↩︎

  7. https://www.postgresql.org/message-id/CAMbWs49-v9FGX+B=tsCxUq_FPX09ZNvXjj+TaTx0m-MAVmY5TA@mail.gmail.com ↩︎

  8. https://www.postgresql.org/message-id/33d590a7-4e26-41a8-acd4-51720dddf969%40eisentraut.org ↩︎

\n", "date_published": "2026-10-21T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/postgresql-comme-bdd-graphe/", "url": "https://www.data-bene.io/fr/blog/postgresql-comme-bdd-graphe/", "title": "PostgreSQL comme base de données graphe, partie 0 : introduction, graphes, bases de données graphe", "content_html": "\n

Cet article est le premier d’une série de quatre dont l’objectif est d’explorer les bases de données graphe et l’évolution du rôle de PostgreSQL dans le domaine. Nous introduirons les concepts fondamentaux puis discuterons de l’implémentation de SQL/PGQ dans PostgreSQL et son avenir. Nous comparerons les performances obtenues face aux solutions graphe sous PostgreSQL (par exemple Apache AGE), puis enfin à la trajectoire plus large des systèmes relationnels intégrant les charges de travail graphe.

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⊆V×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)∈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∈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→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.

\"stp_topology_transparent\"

\"web_graph_transparent\"

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.

\"Exemple

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.

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.

\"Aperçu

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 :

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.

  1. Neo4j store formats ↩︎

  2. Plusieurs images empruntées à Besta, M. et al. (2023). Demystifying Graph Databases: Analysis and Taxonomy of Data Organization, System Designs, and Graph Queries. ACM Computing Surveys, 56(2), Art. 31. ↩︎

\n", "date_published": "2026-10-19T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/ivorysql-5/", "url": "https://www.data-bene.io/fr/blog/ivorysql-5/", "title": "IvorySQL 5.0+ : un tournant pour les transitions Oracle vers PostgreSQL", "content_html": "\n

IvorySQL : « un PostgreSQL avancé, complet, open source, compatible Oracle, avec un engagement ferme de rester toujours 100% compatible et un remplacement direct de la dernière version de PostgreSQL. » (GitHub)

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 :

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 :

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

\n", "date_published": "2026-01-27T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/pgday-cern-2026/", "url": "https://www.data-bene.io/fr/blog/pgday-cern-2026/", "title": "CERN PGDay : un événement PostgreSQL annuel à Genève, Suisse", "content_html": "\n

Si vous résidez près de l’ouest de la Suisse et de la région de Genève (ou que vous souhaitez simplement visiter le coin!), vous tirerez probablement tout intérêt à assister au CERN PGDay 2026. Il s’agit d’une rencontre annuelle (cette année le 6 février 2026) destinée à toute personne souhaitant en apprendre plus sur PostgreSQL, qui se tient au CERN, le plus grand laboratoire de physique des particules au monde.

Si le sujet de la physique des particules vous intéresse, vous voudrez peut-être venir de toute façon ! Le CERN offre un accès gratuit à de nombreuses activités du mardi au dimanche ; vous pouvez consulter le programme complet ici.

Vous pourrez assister à une série de sept sessions en anglais, suivies d’une rencontre sociale pour profiter du CERN tout en continuant à discuter avec les autres participants.

Cette année, le programme inclura :

  1. Un nouveau backend PostgreSQL pour l’ordonnancement de l’archive CERN Tape à destination de la campagne 4 du LHC — Konstantina Skovola, CERN
  2. DCS Data Tools — implémentation PostgreSQL/TimescaleDB pour les données temporelles ATLAS DCS — Dimitrios Matakias, Paris Moschovakos, CERN
  3. Les risques opérationnels de la gestion de bases PostgreSQL de plus de 100 To — Teresa Lopes, Adyen
  4. Le vidage de grandes tables : comment les changements récents de Postgres facilitent davantage les charges de travail critiques — Robert Treat, AWS
  5. Le paysage (très pratique) du sharding Postgres — Álvaro Hernández, OnGres
  6. L’alchimie des shared buffers : équilibrer concurrence et performances — Josef Machytka, credativ
  7. Quand Kafka a rencontré l’Éléphant : une histoire d’amour sur l’ingestion rapide — Barbora Linhartova, Jan Suchanek, Baremon

La première intervention de la journée est particulièrement notoire…

L’archive CERN Tape (CTA) stocke plus d’un exaoctet de données scientifiques. Pour orchestrer les opérations de stockage (archivage) et les opérations d’accès (récupération), l’ordonnanceur CTA coordonne des mouvements de données concurrents sur des centaines de serveurs bande, en s’appuyant sur une base de données d’ordonnancement (Scheduler DB) pour gérer les métadonnées des requêtes en cours. L’architecture existante basée sur un “objectstore” de la base de données d’ordonnancement CTA est un système de gestion transactionnelle complexe. Cette présentation présente le développement d’un nouveau backend PostgreSQL pour l’ordonnanceur CTA comme solution prête à l’emploi qui simplifie l’implémentation et devrait réduire significativement les coûts de développement et opérationnels futurs. Nous décrivons l’implémentation de tous les principaux flux de travail CTA et expliquons comment PostgreSQL répond aux limitations du système basé sur un objectstore, offrant les fondations pour l’augmentation décuplée du débit de données attendue durant la campagne 4 du LHC.

(lien vers la description de l’intervention)

Dans un monde où des quantités toujours plus importantes d’informations numériques doivent être stockées, en apprendre davantage sur la manière dont le CERN gère plus d’un exaoctet de données scientifiques s’avérera sûrement une expérience intéressante.

Genève accueille de nombreuses organisations internationales dans les secteurs public, privé et scientifique. Si vous souhaitez explorer plus en profondeur le sujet de PostgreSQL par le biais de discussions ou de sessions, c’est un lieu agréable pour rencontrer des personnes et apprendre. Vous pensez venir ? Vous pouvez vous inscrire jusqu’au 1er février.

Les enregistrements des sessions de l’année dernière peuvent être consultés en visitant le programme 2025 et en sélectionnant le trombone à côté de l’intervention qui vous intéresse.

Passez nous voir dans la zone de restauration ; nous sommes fiers de sponsoriser à nouveau l’événement cette année et aurons un stand ou un comptoir où vous pourrez nous rendre visite. Nous serions ravis de discuter de PostgreSQL, de l’innovation et du développement open-source, ainsi que de répondre à toutes vos questions.

\n", "date_published": "2026-01-22T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/optimisation-base-de-donnees-et-pollution-mondiale/", "url": "https://www.data-bene.io/fr/blog/optimisation-base-de-donnees-et-pollution-mondiale/", "title": "L'optimisation des bases de données et l'importance de réduire la pollution numérique mondiale", "content_html": "\n

Je repensais au Postgres Ibiza (PGIBZ) qui a eu lieu il y a quelques mois… Et pas seulement parce que la chaleur et le soleil d’Ibiza me manquent, l’hiver étant arrivé à Cognac ! Non, je me souvenais que l’île portait encore les traces des récentes inondations, même si les habitants s’activaient pour effacer les dégâts. Les dernières nouvelles des Caraïbes et d’Asie m’ont fait réaliser qu’Ibiza avait, toutes proportions gardées, été plutôt chanceuse.

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 :

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.

\n", "date_published": "2026-01-19T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/open-source-experience-2025/", "url": "https://www.data-bene.io/fr/blog/open-source-experience-2025/", "title": "Open Source Experience 2025", "content_html": "\n

L’édition 2025 de l’Open Source Experience (OSXP) s’est tenue les 10 et 11 décembre sous le thème « Open Source, clé de l’autonomie stratégique de l’Europe ». L’accent portait, comme vous l’imaginez, entièrement sur la redéfinition de l’avenir numérique européen comme étant mené par les innovations open source à travers toutes les technologies (incluant la gestion des données, le cloud et la cybersécurité). Cette année, de nombreuses conférences se sont largement concentrées sur l’intersection entre l’open source et les technologies d’IA (en accord avec l’accent que l’industrie technologique a mis sur l’IA en général, en 2025).

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 :

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 !

\n", "date_published": "2026-01-03T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/postgres-ibiza-2025/", "url": "https://www.data-bene.io/fr/blog/postgres-ibiza-2025/", "title": "PGIBZ 2025 : un événement pour la communauté Postgres à Ibiza", "content_html": "\n

Postgres Ibiza (PGIBZ) : une conférence open source conçue pour rassembler des personnes passionnées par PostgreSQL à Ibiza, un lieu détendu propice à des discussions fraîches et innovantes. Un événement international organisé par l’association à but non lucratif PostgreSQL España.

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

\n", "date_published": "2025-12-11T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/transitionnez-facilement-vers-postgresql-depuis-oracle/", "url": "https://www.data-bene.io/fr/blog/transitionnez-facilement-vers-postgresql-depuis-oracle/", "title": "Transitionnez facilement vers PostgreSQL depuis Oracle", "content_html": "\n

Si vous avez besoin de transition rapidement d’Oracle vers PostgreSQL, sans vous préoccuper des conversions de types ou autres packages Oracle qui nécessitent des modifications pour être compatible PostgreSQL, une solution utile est IvorySQL !

Introduction

De plus en plus d’entreprises cherchent à se libérer des coûts et des contraintes d’Oracle en migrant vers PostgreSQL. Mais comment réussir cette transition sans y passer des mois ? Voici une méthode éprouvée, rapide et sécurisée, basée sur des retours d’expérience et des outils open source.

Commencer par évaluer et cartographier

Avant de migrer, il est essentiel de faire l’état des lieux : lister les objets Oracle par une extraction complète (tables, vues, séquences, procédures, fonctions, packages).

Mais aussi avoir des échanges réguliers avec le client pour affiner les constats et valider les orientations, mais aussi d’identifier les dépendances (applications connectées avec quelle technologie, jobs, interfaces,…)

Et enfin, repérer les spécificités Oracle du client (fonctions spécifiques comme ROWID, DUAL, DBMS_XXX,…) et tout autre mot-clé demandant une attention particulière.

Choisir les bons outils open source

La réussite d’une transition vers PostgreSQL - car il s’agit bien d’une transition progressive et non d’une migration - repose autant sur la stratégie que sur les outils.

Il ne suffit pas de copier des objets : il faut comprendre les subtilités du moteur Oracle et les transposer intelligemment dans l’univers PostgreSQL.

Parmi les outils incontournables, Ora2Pg joue un rôle central. Il permet non seulement de générer des rapports d’inventaire clairs, mais aussi d’automatiser la conversion des schémas, des données et du code PL/SQL. C’est un accélérateur précieux pour les projets bien structurés.

Mais dans certains contextes, la réalité est plus complexe. De nombreux clients accumulent une dette technique importante, avec des milliers de lignes de code procédural. Tenter de tout réécrire en PL/pgSQL dans un délai court reviendrait à épuiser les équipes, tout en compromettant la migration elle-même. Maintenir deux bases de code — l’une en PL/SQL, l’autre en PL/pgSQL — pendant une phase de transition complète est souvent intenable sur le plan organisationnel.

C’est précisément là qu’IvorySQL offre une alternative puissante. Ce fork de PostgreSQL, enrichi de compatibilités Oracle (PL/SQL, ROWID, DUAL, etc.), permet de réduire considérablement le besoin de réécriture immédiate. En combinant IvorySQL avec une documentation ciblée et des scripts de validation métier, on obtient une transition plus rapide, plus fiable, et surtout mieux maîtrisée.

Une fois en production, les équipes disposent du temps nécessaire pour réécrire progressivement leur code procédural en PL/pgSQL, sans pression ni rupture fonctionnelle.

Intégration et tests

L’un des grands avantages d’IvorySQL, c’est qu’il réalise une partie de l’intégration en amont. Grâce à son support natif du PL/SQL, des objets Oracle et de la syntaxe Oracle-compatible, de nombreux éléments migrés via Ora2Pg fonctionnent immédiatement sans adaptation lourde.

Cela ne dispense évidemment pas d’une phase de test, bien au contraire : il est essentiel de valider les comportements métier dans un environnement de préproduction IvorySQL. Les procédures, fonctions, packages, triggers et vues doivent être testés avec des cas réels, en comparant les résultats entre Oracle et IvorySQL pour garantir l’équivalence fonctionnelle.

Des scripts de comparaison peuvent être utilisés pour vérifier les réponses aux requêtes, les effets des transactions, ou les comportements des fonctions migrées. Mais dans bien des cas, IvorySQL permet de réduire considérablement le besoin de patchs ou de réécriture, ce qui accélère la mise en production et sécurise la transition.

Documenter et accompagner

Une transition réussie ne se limite pas à la technique : elle repose aussi sur une documentation claire et un accompagnement adapté. Il est essentiel de rédiger des cahiers de tests entiers et exhaustifs par objet complexe et modules (procédure, package, trigger…), afin de garder une trace des choix techniques, des adaptations réalisées, et des points d’attention.

L’accompagnement des équipes client est tout aussi important. Des ateliers ciblés permettent de transmettre les bonnes pratiques, d’expliquer les différences entre Oracle et PostgreSQL, et de faciliter la prise en main d’IvorySQL.

Enfin, la réussite d’une transition vers PostgreSQL repose aussi sur l’accompagnement des équipes techniques et fonctionnelles. Des sessions de formation ciblées permettent aux développeurs, DBA et chefs de projet de s’approprier les spécificités d’IvorySQL, de comprendre les différences avec Oracle, et de monter en compétence rapidement.

Ce dispositif s’appuie également sur un support technique structuré, qui aide à résoudre les blocages, à sécuriser les choix d’implémentation, et à fluidifier les échanges entre les équipes projet et les experts migration.

IvorySQL dans le monde réel

Lors d’une mission récente pour une entreprise du secteur privé, nous avons accompagné la transition d’une base Oracle vers IvorySQL dans un contexte contraint : dette technique importante, volumétrie élevée, et délais serrés.

Grâce à IvorySQL et notre capacité à automatiser cette transition, cette transition s’est faite rapidement et la quasi totalité des objets ont été intégrés sans réécriture.

La bascule d’IvorySQL vers PostgreSQL peut s’effectuer sereinement, dans la mesure où l’application fonctionne pleinement et répond aux attentes métier.

Les équipes ont pu se concentrer sur les tests métier, tandis que la formation ciblée et le support technique ont permis une montée en compétence rapide.

Il est indispensable de réussir ce genre de projet pour emmagasiner de la confiance et développer cette opération sur la totalité de votre parc d’instances Oracle !

Vous envisagez une transition Oracle vers PostgreSQL ? Parlons-en.

Contactez notre équipe d’experts, à tout moment: contact@data-bene.io

Le 26 novembre 2025, IvorySQL 5.0 a été publié - voir l’annonce ici pour plus d’informations sur ce projet open source.

\n", "date_published": "2025-12-10T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/le-saviez-vous-les-tables-dans-postgresql-sont-limitees-a-1600-colonnes/", "url": "https://www.data-bene.io/fr/blog/le-saviez-vous-les-tables-dans-postgresql-sont-limitees-a-1600-colonnes/", "title": "Le saviez-vous ? Les tables dans PostgreSQL sont limitées à 1600 colonnes", "content_html": "\n

Saviez-vous qu’une table ne peut pas contenir plus de 1 600 colonnes ? Cet article de blog est inspiré d’une conversation avec Pierre Ducroquet.

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\n#define MaxHeapAttributeNumber\t1600

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\n\nDO $$\nDECLARE\n    i int;\nBEGIN\n    EXECUTE 'DROP TABLE IF EXISTS tint_1601;';\n    EXECUTE 'CREATE TABLE tint_1601(i_1 int);';\n    FOR i IN 2..1601 LOOP\n        EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);\n    END LOOP;\nEND $$;

Le résultat est le suivant :

NOTICE:  table \"tint_1600\" does not exist, skipping\nERROR:  tables can have at most 1600 columns\nCONTEXT:  SQL statement \"ALTER TABLE tint_1600 ADD COLUMN i_1601 int;\"\nPL/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 $$\nDECLARE\n    i int;\nBEGIN\n    EXECUTE 'DROP TABLE IF EXISTS tint_1600;';\n    EXECUTE 'CREATE TABLE tint_1600(i_1 int);';\n    FOR i IN 2..1600 LOOP\n        EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);\n    END LOOP;\nEND $$;

Construisons puis insérons un tuple de 1600 colonnes :

DO $$\nDECLARE\n    s TEXT;\n    rows_inserted int;\nBEGIN\n    s := format(\n                 'INSERT INTO tint_1600 VALUES (1%s);'\n               , repeat( ',1' , 1599 )\n               );\n    EXECUTE s;\n\n    GET DIAGNOSTICS rows_inserted = ROW_COUNT;\n    RAISE NOTICE 'Rows inserted: %', rows_inserted;\nEND $$;

The output is:

NOTICE:  Rows inserted: 1\nDO

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)\nDO $$\nDECLARE\n    i int;\nBEGIN\n    EXECUTE 'DROP TABLE IF EXISTS tint_1600;';\n    EXECUTE 'CREATE TABLE tint_1600(i_1 int);';\n    FOR i IN 2..1600 LOOP\n        EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);\n    END LOOP;\nEND $$;\n\n-- Insert a tuple - 1 x int + 1599 x char(127)\nDO $$\nDECLARE\n    s TEXT;\nBEGIN\n    s := format(\n                 'INSERT INTO tint_1600 VALUES (1%s);'\n               , repeat( $q$,'1'::char(127)$q$ , 1599 )\n               );\n    EXECUTE s;\nEND $$;```\n\nLe résultat est :

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

\nComme 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.\n\n## Quid des JOINs ?\n\nPour simplifier, testons avec une jointure automatique :\n\n```sql\nSELECT a.*,b.* FROM tint_1600 a, tint_1600 b;\nERROR:  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);\n\nCREATE TABLE\n\n=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;\n\nALTER TABLE\n\n=# SELECT attname,attnum,attstorage,attnotnull,attisdropped\n   FROM pg_attribute\n   WHERE attrelid=(\n                   SELECT oid\n                   FROM pg_class\n                   WHERE relname='tadc_1600'\n                   )\n     AND attnum > 0 ORDER BY attnum;\n\n attname | attnum | attstorage | attnotnull | attisdropped\n---------+--------+------------+------------+--------------\n i_1     |      1 | p          | t          | f\n i_2     |      2 | p          | t          | f\n(2 rows)\n\n=# ALTER TABLE tadc_1600 DROP COLUMN i_2;\n\nALTER TABLE\n\n=# SELECT attname,attnum,attstorage,attnotnull,attisdropped\n   FROM pg_attribute\n   WHERE attrelid=(\n                   SELECT oid\n                   FROM pg_class\n                   WHERE relname='tadc_1600'\n                   )\n     AND attnum > 0 ORDER BY attnum;\n\n           attname            | attnum | attstorage | attnotnull | attisdropped\n------------------------------+--------+------------+------------+--------------\n i_1                          |      1 | p          | t          | f\n ........pg.dropped.2........ |      2 | p          | f          | t\n(2 rows)

Lors de la suppression d’une colonne, cette colonne

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\nDO $$\nDECLARE\n    i int;\nBEGIN\n    EXECUTE 'DROP TABLE IF EXISTS tadc;';\n    EXECUTE 'CREATE TABLE tadc(i_1 int);';\n    FOR i IN 2..1601 LOOP\n        EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);\n        EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);\n    END LOOP;\nEND $$;

Le résultat est :

ERROR:  tables can have at most 1600 columns\nCONTEXT:  SQL statement \"ALTER TABLE tadc ADD COLUMN i_1601 int;\"\nPL/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\n   FROM pg_attribute\n   WHERE attrelid=(\n                   SELECT oid\n                   FROM pg_class\n                   WHERE relname='tadc'\n                   )\n     AND attnum > 0 ORDER BY attnum;\n\n             attname             | attnum | attstorage | attnotnull | attisdropped\n---------------------------------+--------+------------+------------+--------------\n i_1                             |      1 | p          | t          | f\n ........pg.dropped.2........    |      2 | p          | f          | t\n ........pg.dropped.3........    |      3 | p          | f          | t\n ........pg.dropped.4........    |      4 | p          | f          | t\n ........pg.dropped.5........    |      5 | p          | f          | t\n\n ........pg.dropped.1599........ |   1599 | p          | f          | t\n ........pg.dropped.1600........ |   1600 | p          | f          | t\n(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

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

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.

\n", "date_published": "2025-11-13T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/statistiques-cumulatives-dans-postgresql-18/", "url": "https://www.data-bene.io/fr/blog/statistiques-cumulatives-dans-postgresql-18/", "title": "Statistiques cumulatives dans PostgreSQL 18", "content_html": "\n

Dans PostgreSQL 18, le sous-système de statistiques et de supervision bénéficie d’une refonte majeure: statistiques cumulatives étendues, nouvelle visibilité I/O par backend, possibilité pour les extensions d’exporter / importer / ajuster les statistiques, et améliorations des contrôles GUC ainsi que du comportement de cache et de snapshot. Ces changements ouvrent de nouvelles perspectives pour l’analyse de performance, la simulation inter-environnements et une meilleure intégration avec les extensions. Dans cet article, j’explore les nouveautés, les points d’attention, les paramètres GUC, ainsi que la manière dont les auteurs d’extensions peuvent exploiter la nouvelle API en C.

Introduction & motivation

Les statistiques (au sens large: compteurs de supervision, métriques I/O, et estimations pour le planificateur / optimiseur) sont au cœur à la fois de l’optimisation de performance et des décisions internes de PostgreSQL. Des statistiques transparentes, fiables et manipulables permettent entre autres aux DBAs d’adresser directement l’efficacité de PostgreSQL, et donnent aux «extensions» la possibilité d’améliorer l’expérience utilisateur.

Cela dit, le système historique de statistiques de PostgreSQL n’était pas exempt de frictions: capacité limitée à réinitialiser les statistiques des relations, métriques exprimées dans des unités pas toujours alignées avec les besoins utilisateurs, absence d’API C pour utiliser le moteur de statistiques cumulatives de PostgreSQL. PostgreSQL 18 répond directement à ces préoccupations.

Voici un résumé des améliorations clés.

Un avertissement sur les statistiques

Bien que les statistiques soient extrêmement utiles, leur collecte peut consommer du temps et des ressources. PostgreSQL 18 introduit un point important: avec l’élargissement du spectre des métriques collectables, la taille maximale de la table de hachage a été augmentée. Gardez cela à l’esprit, surtout si vous concevez des systèmes à grande échelle avec des architectures «un ensemble de tables par client»: on a constaté que la limite de 1 Go pouvait être atteinte avec quelques millions de tables.

Quoi de neuf dans PostgreSQL 18 et les « stats »

Voici les nouvelles fonctionnalités majeures ou les améliorations concernant les statistiques et la supervision.

De manière générale, pg_stat_io rapporte désormais l’activité I/O en octets plutôt qu’en pages, ce qui est plus pratique pour l’analyse. De plus, les statistiques WAL y ont été déplacées depuis pg_stat_wal, offrant ainsi une vue unique et complète.

Mises à jour

pg_upgrade est désormais capable de conserver les statistiques de l’optimiseur, supprimant la nécessité de relancer un ANALYZE complet pour obtenir de bons plans de requêtes après une montée de version: une avancée très attendue pour les grandes bases!

Attention toutefois: les statistiques personnalisées ajoutées par une extension ainsi que celles créées avec CREATE STATISTICS ne sont pas conservées.

Vous voudrez sûrement examiner les nouvelles options de vacuumdb (--missing-stats-only) pour n’analyser que ce qui est nécessaire.

Dans la même veine, l’option --[no-]statistics a été ajoutée à pg_dump, pg_dumpall, et pg_restore.

Maintenance

Il est désormais plus simple d’évaluer l’effort de maintenance sur les objets, puisque le temps total passé dans les opérations VACUUM et ANALYZE (y compris
automatiques) est rapporté dans pg_stat_all_tables et ses variantes.

Un nouveau GUC à ne pas oublier: track_cost_delay_timing. Il collecte le temps passé à dormir (suite aux opérations retardées) pour VACUUM et ANALYZE. Très intéressant, mais comme les autres GUC track_io*, il multiplie les appels à l’horloge système, ce qui peut provoquer un impact sévère sur certaines plateformes. Toujours vérifier avec un outil comme pg_test_timing pour s’assurer que votre système peut le supporter!

Plus de questions sur l’activité du checkpointer grâce à pg_stat_checkpointer. Le nouvel attribut num_done indique le nombre de checkpoints terminés. Vous pouvez aussi savoir quel type de buffers a été écrit grâce à slru_written, et buffers_written qui ne concerne désormais que shared_buffers: auparavant, journal et vue n’affichaient pas les mêmes totaux, car un compteur SLRU existait dans un cas mais pas dans l’autre.

Analyse

Envie d’en savoir plus sur l’I/O traité par un backend (PID) ? Appelez pg_stat_get_backend_io(int) et vous obtiendrez une sortie similaire à la vue pg_stat_io, mais pour ce processus. Pour les stats WAL de ce PID: utilisez pg_stat_get_backend_wal(int).

De nouveaux attributs parallel_workers_to_launch et parallel_workers_launched apparaissent dans pg_stat_database. Le ratio permet de savoir si nous avons assez de slots pour les workers parallèles.

Changements intéressants dans pg_stat_statements: plus de requêtes seront regroupées sous le même identifiant. Par exemple, les
motifs IN (1,2,3, ...) n’utiliseront que la première et la dernière constante. Un changement plus contre-intuitif concerne le nom de table utilisé dans une requête: seul le nom est pris en compte, pas le schéma ni l’OID de relation. Cela permet de suivre les tables supprimées ou recréées, mais cela peut aussi regrouper les stats de tables sans lien ayant simplement le même nom. Pour séparer les stats de tables homonymes, il faudra les aliaser dans les requêtes (FROM my.table mt, other.table ot)…

Enfin, ajouts à pg_backend_memory_contexts avec path (pour récupérer parent/enfant) et type pour distinguer les contextes AllocSet, Generation, Slab et Bump… Et au fait, que sont Slab et Bump ? Pas documentés ; il faut lire les en-têtes des fichiers C ici. Ils existent pour optimiser l’allocation, la réallocation et la réinitialisation mémoire selon les usages attendus. Par exemple, Slab est défini comme un «MemoryContext implementation designed for cases where large numbers of equally-sized objects can be allocated and freed efficiently with minimal memory wastage and fragmentation».

Ah, non, encore une dernière: wal_buffers_full a été ajouté à pg_stat_statements pour permettre un meilleur réglage de wal_buffers.

Réplication

De meilleures informations apparaissent désormais pour la gestion des conflits en réplication logique grâce à de nouveaux attributs dans pg_stat_subscription_stats. En référence, cet extrait du commit liste les attributs introduits:

Avancé

Un nouveau jeu de fonctions permet désormais de gérer les statistiques de relations et d’attributs (relpages, avg_width, etc.). Cela offre la possibilité d’exporter, importer et ajuster les stats à volonté, afin de répliquer le comportement du planificateur hors production, de maintenir des stats corrigées, et plus encore.

Mon préféré pour les auteurs d’extensions: la nouvelle API C de stats

L’une des évolutions les plus enthousiasmantes est ce que PostgreSQL 18 ouvre aux auteurs d’extensions.

Cette petite ligne au bas de la section E.1.3.9 Modules est celle qui nous intéresse :

Allow extensions to use the server’s cumulative statistics API (Michael Paquier)

Jusqu’ici, la manipulation des statistiques était réservée à l’interne ; désormais, une API officielle et structurée est disponible pour construire (ou envelopper) autour.

Le message de commit est bien rédigé et couvre l’essentiel des nouveautés. Un sous-ensemble des options est détaillé dans la documentation. Cependant, il faut encore plonger dans le code source pour en savoir plus ; en particulier, il vaut la peine de regarder l’extension injection points (fournie avec PostgreSQL) qui utilise cette nouvelle API.

Pour aller plus loin sur la manière dont une extension peut exploiter ces nouvelles capacités, vous pourrez bientôt découvrir PACS (PostgreSQL Advanced Cumulative Statistics) sur Codeberg : mon projet qui propose une bibliothèque de wrappers et des utilitaires autour des nouvelles APIs de statistiques de PostgreSQL 18.

En attendant, la présentation que j’ai donnée à FOSDEM 2025 explore ce sujet plus en détail.

\n", "date_published": "2025-09-29T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/base-de-donnees-la-plus-desiree-trois-annees-consecutives/", "url": "https://www.data-bene.io/fr/blog/base-de-donnees-la-plus-desiree-trois-annees-consecutives/", "title": "Base de données la plus désirée trois années consécutives : L'attrait de PostgreSQL pour les développeurs", "content_html": "\n

PostgreSQL vit plus qu’un simple moment de gloire—elle établit un schéma clair d’excellence soutenue. Pour la troisième année consécutive, cette base de données pilotée par la communauté a revendiqué la première place dans les résultats 2025 de l’enquête annuelle des développeurs de Stack Overflow, et les résultats révèlent à la fois ce que les développeurs valorisent aujourd’hui et où se dirige le paysage des bases de données.

Les résultats de l’enquête montrent que PostgreSQL est classée au plus haut rang parmi toutes les technologies de bases de données pour les développeurs qui veulent l’utiliser dans la prochaine année (47%) ou l’ont utilisée cette année et veulent continuer à l’utiliser l’année prochaine (66%) pour la troisième année d’affilée.

Les chiffres racontent une histoire convaincante

Les données de l’enquête de plus de 49 000 développeurs à travers 177 pays fournissent une preuve claire de l’attrait soutenu de PostgreSQL. Depuis 2023, PostgreSQL s’est constamment classée comme la technologie de base de données la plus désirée et la plus admirée parmi les développeurs.

En regardant les mesures spécifiques des visualisations de l’enquête, PostgreSQL mène avec 46,5% des développeurs voulant travailler avec elle dans l’année à venir, tandis qu’un impressionnant 65,5% de ceux qui l’ont utilisée veulent continuer à le faire. Ce ne sont pas seulement des chiffres impressionnants—ils représentent une cohérence qui est rare dans le paysage technologique en rapide évolution.

Les données de l’enquête révèlent également un schéma intéressant parmi les développeurs utilisant actuellement d’autres technologies de bases de données. Les développeurs travaillant avec MongoDB et Redis montrent un désir particulièrement fort d’ajouter PostgreSQL à leur boîte à outils l’année prochaine, voyant la valeur d’ajouter des compétences en bases de données relationnelles à leur répertoire.

L’avantage communautaire en action

Pourquoi PostgreSQL a-t-elle atteint ce niveau de succès soutenu ? La réponse réside dans son modèle de développement piloté par la communauté. En tant que projet open source, PostgreSQL bénéficie d’un développement collaboratif qui est à la fois transparent et réactif aux besoins du monde réel.

Le projet PostgreSQL représente le meilleur de ce que le développement piloté par la communauté peut accomplir. Avec plus de 400 contributeurs de code à travers plus de 140 entreprises de soutien, le projet se vante de plus de 55 000 commits et plus de 1,6 million de lignes de code soigneusement élaboré. Cette approche diverse et globalement distribuée du développement résulte en des tests plus approfondis, des corrections de bogues plus rapides, et des fonctionnalités plus innovantes que les modèles de développement commercial traditionnels n’atteignent typiquement.

Les versions majeures sont publiées annuellement avec approximativement 180 fonctionnalités par version, complétées par des versions mineures trimestrielles qui incluent de nombreuses améliorations et corrections. Cette cadence régulière d’innovation constamment contribuée par des individus partout dans le monde assure que PostgreSQL ne fait pas que suivre le rythme des besoins des développeurs—elle les anticipe. Plus que cela, chaque individu a la capacité de contribuer au projet pour s’assurer que partout où le logiciel prend du retard, la fonctionnalité change pour répondre aux demandes modernes.

Plus qu’une simple base de données relationnelle

Un facteur clé dans l’attrait large de PostgreSQL est qu’elle n’est pas limitée à être juste un système de base de données relationnelle. PostgreSQL est objet-relationnelle par conception, capable de gérer des types de données diverses incluant JSON/JSONB, XML, Clé-Valeur, géométriques, géospatiales, UUID natif, et données de séries temporelles. Cette polyvalence explique pourquoi les développeurs de milieux NoSQL trouvent PostgreSQL attractive—elle offre la fiabilité relationnelle tout en maintenant la flexibilité à laquelle ils sont habitués.

Le soutien étendu pour différents types de données, combiné avec les caractéristiques ACID (Atomicité, Cohérence, Isolation, Durabilité), permet une gestion de données optimisée, performante, et fiable indépendamment des exigences spécifiques en place. De plus, l’énorme réseau d’extensions piloté par la communauté de PostgreSQL s’appuie sur son extensibilité native, fournissant des solutions pour la gestion géospatiale, la récupération après sinistre, l’infrastructure de haute disponibilité, la surveillance, l’audit, et bien plus.

Le paysage plus large des bases de données

Tandis que PostgreSQL domine les positions de tête, l’enquête révèle un écosystème de bases de données sain et compétitif. Les classements complets montrent :

Bases de données les plus désirées :
• PostgreSQL : 46,5%
• SQLite : 28,3%
• Redis : 23,5%
• MySQL : 20,5%
• MongoDB : 17,6%

Bases de données les plus admirées :
• PostgreSQL : 65,5%
• SQLite : 59%
• Redis : 54,9%
• MongoDB : 45,7%
• MySQL : 43,2%

Ces chiffres reflètent un écosystème diversifié où différentes bases de données servent des objectifs spécifiques. La forte performance de SQLite souligne l’importance continue des solutions légères et intégrées. Redis maintient sa position comme une base de données spécialisée hautement considérée pour la mise en cache et les applications temps réel. Les bases de données traditionnelles comme MySQL et Microsoft SQL Server continuent de détenir des positions significatives, tandis que les nouvelles technologies comme DuckDB montrent des scores d’admiration impressionnants malgré des taux d’utilisation plus faibles.

La fondation du succès durable de PostgreSQL

Trois années consécutives au sommet des préférences des développeurs n’arrive pas par accident. La domination soutenue de PostgreSQL découle de forces fondamentales qui continuent de bien servir les développeurs alors que les paysages technologiques changent. La résilience intégrée dans PostgreSQL à travers son modèle de développement piloté par la communauté signifie qu’elle s’adapte sans perdre la stabilité. Son extensibilité la distingue de manières pratiques—plutôt que d’attendre les feuilles de route des fournisseurs ou de s’inquiéter des lacunes de fonctionnalités, les développeurs peuvent construire ce dont ils ont besoin ou tirer parti de l’écosystème étendu d’extensions communautaires. La nature open source assure que PostgreSQL reste focalisée sur les besoins des développeurs plutôt que sur les modèles d’affaires, avec des corrections de bogues qui se produisent rapidement et des fonctionnalités qui se développent basées sur des cas d’usage du monde réel.

Après 35 ans de développement actif et trois années consécutives comme la technologie de base de données la plus désirée, PostgreSQL a prouvé que le développement open source piloté par la communauté peut livrer à la fois une utilité immédiate et une valeur à long terme. Pour les développeurs et organisations regardant leurs choix de bases de données, PostgreSQL offre quelque chose d’increasingly rare : une technologie qui s’améliore avec le temps sans laisser ses utilisateurs derrière.

\n", "date_published": "2025-08-09T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/retour-de-how2025/", "url": "https://www.data-bene.io/fr/blog/retour-de-how2025/", "title": "Retour de HOW2025", "content_html": "\n

Les 27 et 28 juin se tenaient les conférences Highgo Open World, consacrées à l’écosystème PostgreSQL et au projet IvorySQL. Côté chiffres, le succès est notable : près de 1 000 participants sur place, jusqu’à 8 000 connexions simultanées sur les streams, et environ 25 000 spectateurs au total.

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 :

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.

\n", "date_published": "2025-07-14T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/scale-22x-r%C3%A9unir-la-communaut%C3%A9-open-source-%C3%A0-pasadena/", "url": "https://www.data-bene.io/fr/blog/scale-22x-r%C3%A9unir-la-communaut%C3%A9-open-source-%C3%A0-pasadena/", "title": "SCaLE 22x : réunir la communauté open source à Pasadena", "content_html": "\n

Le Southern California Linux Expo (SCaLE) 22x, reconnu comme la plus grande conférence d’Amérique du Nord gérée par la communauté et axée sur l’open source et le logiciel libre, s’est tenu au Pasadena Convention Center du 6 au 9 mars 2025. Quand je dis géré par la communauté, je le pense vraiment — pas de patrons corporatifs dictant l’agenda, juste un pur enthousiasme open source qui anime quatre jours de discussions techniques et de collaboration.

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.

\n", "date_published": "2025-06-02T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/sauvegarde-sans-reseau/", "url": "https://www.data-bene.io/fr/blog/sauvegarde-sans-reseau/", "title": "Il était une fois une base confinée - PostgreSQL, QR Codes et l'art de la sauvegarde sans réseau", "content_html": "\n

📦 Le Fort Knox des bases de données

Il était une fois, dans une salle serveur lointaine, entourée de verre blindé et de béton armé, une base PostgreSQL tellement confinée, tellement isolée, qu’elle ne pouvait que rêver du cloud.

Pas de réseau.

Pas d’USB.

Aucun stockage externe accessible en écriture.

Juste un clavier, un écran, et le bourdonnement des filtres à air de qualité industrielle.

Ce n’était pas un simple environnement “air-gapped”. C’était une zone d’exfiltration zéro, avec une sécurité opérationnelle si rigoureuse qu’on aurait cru qu’elle protégeait des secrets d’État — ou pire, un système bancaire des années 80.

Et pourtant, dans cet oubli numérique, une question demeurait :
Comment sauvegarder une base PostgreSQL sans jamais extraire un seul fichier ?

🎥 Quand l’écran devient ton réseau

Notre client ne voulait pas juste une sauvegarde. Il en avait besoin. La crainte n’était pas le vol, mais la perte totale : une carte mère qui meurt en silence, enfermant les données à jamais dans sa cage de verre. Et dans ce cas, casser le mur à la masse n’est pas un plan de reprise d’activité très élégant.

Nous avons envisagé toutes les options :

Et puis, l’illumination : les QR codes.

Et si on faisait un pg_dump de la base…

…en QR codes…

…affichés à l’écran…

…filmés par une caméra haute fréquence…

…puis reconstitués image par image à l’extérieur ?

C’était absurde. Donc forcément prometteur.

🧠 Hacking pg_dump : la version pixelisée

L’outil adoré pg_dump de PostgreSQL est modulaire. On l’a donc enrichi d’un nouvel “archiver” : --format=qrcode.

Voici le fonctionnement :

  1. Encodage QR : chaque portion de sortie SQL est convertie en QR code (format PNG).
  2. Streaming : au lieu de sauvegarder les images, on les envoie directement sur stdout.
  3. Mise en page : notre interface affiche plusieurs QR codes à l’écran en haute résolution (on parle de 2000+ pixels — de quoi afficher une grille bien dense).
  4. Capture vidéo : une machine dédiée avec une caméra 1280Hz filme l’écran et enregistre la séquence complète.

Pas de macros. Pas de tricherie. Juste des photons et des images.

🔍 Reconstruction à la sortie de la cage

Une fois la vidéo extraite du cube de verre :

Et voilà : la base renaît — entièrement exportée sans transfert numérique.
Rien que de la lumière et des lentilles.

🧩 Performances et fidélité

🛡️ Pourquoi c’est important

Ce n’est pas juste une anecdote technique — c’est une preuve que la souplesse de PostgreSQL s’étend jusqu’à l’absurde. Les environnements ultra-sécurisés ne sont pas rares : défense, finance, infrastructures critiques… Et quand les outils classiques ne suffisent plus, l’architecture extensible de PostgreSQL permet d’innover, même en milieu extrême.

Chez Data Bene, on vit pour ce genre de défi. Optimiser les plans d’exécution ou imaginer des méthodes d’exfiltration qui ressemblent à de l’espionnage, c’est notre terrain de jeu.

Envie d’essayer ? Écrivez-nous — on adore les sauvegardes bizarres.

Et si jamais vous pensez à utiliser pg_restore en spectacle laser, appelez-nous. On est curieux.

\n", "date_published": "2025-04-01T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/postgres-cafe-contribuer-a-l-open-source/", "url": "https://www.data-bene.io/fr/blog/postgres-cafe-contribuer-a-l-open-source/", "title": "Postgres Café : Contribuer à l'Open Source", "content_html": "\n

C’est notre sixième épisode de Café Postgres, un podcast collaboratif de Data Bene & Xata où nous discutons de tout, des extensions PostgreSQL aux contributions de la communauté. Dans l’épisode d’aujourd’hui, Sarah Conway et Gülçin Yıldırım Jelinek recontrent Andrea Cucciniello pour discuter de la manière dont les entreprises et les particuliers peuvent contribuer aux projets open source, et des raisons pour lesquelles ils pourraient envisager de le faire.

É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.

\n", "date_published": "2025-03-04T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/postgres-cafe-deployer-postgresql-distribue-a-grande-echelle-avec-citus-data/", "url": "https://www.data-bene.io/fr/blog/postgres-cafe-deployer-postgresql-distribue-a-grande-echelle-avec-citus-data/", "title": "Postgres Café : Déployer PostgreSQL distribué à grande échelle avec Citus Data", "content_html": "\n

C’est l’heure du quatrième épisode de Café Postgres, un podcast de nos équipes de Data Bene et Xata où nous discutons de la contribution à PostgreSQL et du développement d’extensions. Dans ce dernier épisode, Sarah Conway et Gülçin Yıldırım Jelinek rencontrent Stéphane Carton pour parler de Citus Data, une extension entièrement open source de Microsoft qui permet de déployer PostgreSQL distribué à grande échelle.

Épisode 4 : Citus Data

La base de données Citus a connu 127 versions depuis le 24 mars 2016, date à laquelle elle est passée pour la première fois gratuite et open source pour son utilisation et ses contributions. Il s’agit d’un outil puissant qui fonctionne nativement avec PostgreSQL et s’intègre de manière transparente à tous les outils et extensions Postgres. Voici un résumé des points abordés dans cet épisode de podcast !

Répondre aux problématiques d’évolutivité, de performance et de gestion des grands jeux de données

Pourquoi Citus Data existe-t-il et quels problèmes résout-il ? Examinons cela par catégorie.

Développement

Citus est conçu pour résoudre le problème de la modélisation des données distribuées en fournissant des méthodes de cartographie de la charge de travail dans les modèles de données distribuées, telles que des tables de partitionnement basées sur des clés primaires (particulièrement utiles pour les microservices et les charges de travail à haut débit).

Évolutivité

En distribuant les données sur plusieurs nœuds, vous pouvez activer la mise à l’échelle horizontale des bases de données PostgreSQL.

Cela permet aux développeurs de combiner les capacités des processeurs, de mémoire, de stockage et des E/S de plusieurs machines pour gérer de grands ensembles de données et des charges de travail à trafic élevé. Il est possible d’ajouter facilement davantage de nœuds au cluster et de rééquilibrer les partitions au fur et à mesure que votre volume de données augmente.

Performance

Le moteur de requêtes distribué de Citus est utilisé pour maximiser l’efficacité, en parallélisant les requêtes et en regroupant l’exécution de plusieurs nœuds de travail.

Même lorsque des milliers, voire des millions d’instructions sont exécutées par seconde, l’ingestion de données est toujours optimisée via la récupération des bonnes partitions, la connexion aux nœuds appropriés et la parallélisation de certaines opérations. Tout cela garantit un débit élevé et une latence faible lors du traitement des données en temps réel.

Haute disponibilité et redondance

Grâce au modèle de données distribué, vous pouvez créer des copies redondantes des tables et des partitions sur plusieurs nœuds. Cela permet de garantir que la base de données reste résiliente et disponible même en cas de panne de nœuds, et maintenir ainsi une haute disponibilité.

Contribution à Citus

Chez Data Bene, notre objectif est de soutenir la dynamique du code source grâce au développement continu et aux contributions au code. Cédric Villemain, entre autres membres de notre équipe, évalue constamment de nouveaux ajouts de fonctionnalités ou autres améliorations qui peuvent faire une différence pour les utilisateurs.

Que vous fassiez partie d’une équipe DevOps qui cherche à créer une architecture distribuée pour vos instances PostgreSQL, ou que vous soyez un utilisateur final tel qu’un analyste commercial qui recherche des performances efficaces lors du traitement de grandes quantités de données, Citus Data peut être le meilleur choix.

Si vous avez des demandes ou des intérêts particuliers en matière de fonctionnalités, notre équipe de Data Bene vous aidera à contribuer directement à Citus Data ou pourra le faire en votre nom pour garantir la longévité du projet Citus et sa pertinence pour vos projets. Apprenez-en davantage sur la contribution à Citus Data en vous référant au dépôt officiel CONTRIBUTING.md.

Regardez l’épisode complet

Vous envisagez de regarder la discussion complète ? Découvrez-le sur YouTube :

Découvrez d’autres outils Postgres

D’autres épisodes sont en cours de publication au Postgres Café ! Abonnez-vous à la playlist pour plus d’interviews sur des outils open source comme StatsMgr pour une gestion efficace des statistiques PostgreSQL, pgzx pour la création d’extensions PostgreSQL à l’aide de Zig, etc. Laissez les experts vous présenter de nouvelles extensions à essayer pour optimiser vos déploiements Postgres.

\n", "date_published": "2025-01-29T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/postgres-cafe-developpez-vos-capacities-de-surveillance-avec-statsmgr/", "url": "https://www.data-bene.io/fr/blog/postgres-cafe-developpez-vos-capacities-de-surveillance-avec-statsmgr/", "title": "Postgres Café : Développez vos capacités de surveillance avec StatsMgr", "content_html": "\n

L’année 2025 a commencé et nous sommes ravis de publier le deuxième épisode de Postgres Café, une série de blogs et de vidéos de nos équipes chez Data Bene et Xata, réalisée dans le but d’explorer le monde de l’open source et de découvrir ses liens avec l’extensibilité de PostgreSQL. Tout au long de cette série, nous discutons de différentes extensions et des outils qui facilitent la vie des développeurs lorsqu’ils travaillent avec PostgreSQL. Dans notre deuxième épisode, nous explorons une toute nouvelle extension PostgreSQL appelée StatsMgr qui exploite les processus en tâche de fond (background workers) et la mémoire partagée pour capturer, gérer et interroger diverses statistiques pour WAL, SLRU, IO, checkpointing, etc.

Épisode 2: StatsMgr

Dans cet épisode nous présentons l’extension open source StatsMgr, récemment publiée, créée pour surveiller et suivre en continu les événements sur PostgreSQL et le système sous-jacent. Voici un aperçu de ce que cet épisode a couvert :

Traitement personnalisé des métriques

À l’origine, l’idée était de fournir une interface simplifiée pour les métriques, tout en les enrichissant avec une grande variété de types disponibles. Cette fonctionnalité a ensuite été étendue pour résoudre des problèmes tels que :

Cette extension est aussi très bien pour gérer des situations telles que lorsque…

Collection étendue et historique de mesures

Actuellement, les types de statistiques pris en charge incluent :

Chacun est enregistré auprès d’un gestionnaire qui vous permet de récupérer et de gérer ces statistiques, et est également accompagné de structures de mémoire partagée pour stocker des instantanés historiques.

Certaines des prochaines étapes du projet comprendront l’ajout de statistiques dynamiques telles que pg_stat_user_tables, entre autres.

Il reste encore beaucoup de choses à faire, des améliorations subtiles aux nouvelles fonctionnalités majeures. Il existe donc bien sûr de nombreuses opportunités de contribuer au projet, que vous soyez un nouveau venu ou un développeur PostgreSQL confirmé. Vous souhaitez participer à l’effort ? Consultez CONTRIBUTING.md dans le projet.

Regardez l’épisode complet

Pour une exploration approfondie de StatsMgr et de ses capacités, regardez l’épisode complet ici :

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

Il y a encore beaucoup à venir sur Postgres Café. Abonnez-vous à la playlist pour découvrir des épisodes qui présentent d’autres outils open source comme pgroll pour les migrations de schémas sans interruption de service, ou Citus Data une extension pour des bases PostgreSQL distribuées et évolutives, et bien plus encore. Restez en contact pour découvrir comment chaque outil peut rendre le travail avec Postgres plus fluide et plus efficace.

\n", "date_published": "2025-01-07T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/transformations-inattendues-de-types-de-donn%C3%A9es/", "url": "https://www.data-bene.io/fr/blog/transformations-inattendues-de-types-de-donn%C3%A9es/", "title": "Transformations inattendues des types de données", "content_html": "\n

Les types de données de votre fonction ont changé et vous n’avez pas été informés

Cet article est le résultat d’une revue de code demandée par l’un de nos clients.

Notre client a exécuté la commande pg_dump --schema-only pour nous fournir
les définitions des objets de niveau database ainsi que le code PLpgsql à auditer.
Jusque là, tout allait bien.

J’ai commencé à lire le code et tout d’un coup je fus pris d’un doute, vous savez
le méchant doute qui vous donne l’impression que votre château de cartes va s’écrouler.
Voici la fonction que j’avais sous les yeux:

CREATE FUNCTION xxx( p_id character, p_info character varying )\nRETURNS integer\nLANGUAGE plpgsql\nAS $$\nDECLARE\nBEGIN\n   ...\n   INSERT INTO t1\n   SELECT * FROM t2 WHERE t2.id = p_id;\n   ...\nEND;\n$$\n;

Peut-être que la première lecture de la fonction ne vous a pas choqué.
Et si je vous disais que la définition de la table t2 ressemble à ce qui suit:

CREATE TABLE t2 (\n   id VARCHAR(130) NOT NULL\n   ...\n   PRIMARY KEY (id)\n);

En pratique t2.id est toujours une chaîne de 130 caractères et il y a 400
millions de tuples dans cette table. Comme vous l’avez déjà probablement compris,
il semble étonnant d’avoir p_id CHARACTER pour manipuler id VARCHAR(130). Pour
mémoire, CHARACTER est l’alias de CHAR(1).

Notre client utilise cette fonction depuis plusieurs années et il n’a pas eu de
problème avec ce code. Néanmoins, notre client m’a dit que la définition de cette
fonction ne correspond pas à ce qu’il a écrit: c’était p_id CHARACTER(130) et
non CHARACTER.

Mais que s’est-il donc passé ? Attaquons la pelotte de laine et voyons si Ariane
nous est d’un grand secours.

CREATE FUNCTION test( c character, d character varying )\nRETURNS void\nLANGUAGE plpgsql\nAS $$\nBEGIN\n  RAISE NOTICE 'c=%, d=%', c,d;\nEND;\n$$;\n\nSELECT test( '123465789', '987654321' );\nNOTICE:  c=123465789, d=987654321\n test \n------\n \n(1 row)

Voilà un résultat bien intéressant: la chaîne ‘123456789’ n’a pas été réduite à
‘1’ (pas de CAST CHAR(1)). Augmentons le niveau de détails:

EXPLAIN (COSTS OFF,ANALYZE,VERBOSE)\n        SELECT test( '123465789', '987654321' );\nNOTICE:  c=123465789, d=987654321\n                             QUERY PLAN                              \n---------------------------------------------------------------------\n Result (actual time=0.040..0.041 rows=1 loops=1)\n   Output: test('123465789'::bpchar, '987654321'::character varying)\n Planning Time: 0.023 ms\n Execution Time: 0.053 ms\n(4 rows)

Nous observons un CAST vers bpchar. Pour mémoire, BPCHAR représente une
chaîne pouvant contenir 10 485 760 caractères. Il est aussi un alias de
CHARACTER ce qui explique partiellement le passage de CHARACTER à BPCHAR.

Explorons une autre facette du problème:

CREATE FUNCTION test(c character(4))\nRETURNS character(4)\nLANGUAGE sql\nAS $$\nselect c;\n$$;

Nous avons changé le langage de la fonction pour savoir si le comportement observé
est propre à PLpgsql. Les données en entrée et en sortie sont de type CHAR(4).
Comment cela va-t-il se comporter ?

SELECT test('123456789');\n   test    \n-----------\n 123456789\n(1 row)\n\nEXPLAIN VERBOSE SELECT test('123456789');\n                QUERY PLAN                 \n-------------------------------------------\n Result  (cost=0.00..0.01 rows=1 width=32)\n   Output: '123456789'::bpchar\n(2 rows)

La bonne nouvelle (si si) c’est que le comportement observé est le même dans
les deux contextes. En revanche, alors que l’on s’attend à manipuler des données
de type CHAR(4), la fonction manipule des données de taille arbitraire (limitée
à ~10M caractères) !!

Cependant, ne vous précipitez pas dans la mailing list de PostgreSQL pour vous plaindre !

En fait, ce comportement n’est pas un bug. La documentation affirme:

“The full SQL type syntax is allowed for declaring a function’s arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) … is exactly the same as CREATE FUNCTION foo (varchar) …”

Ceci explique que CHARACTER(x) devient CHARACTER transformé (par aliasing)
en BPCHAR qui n’est pas CHAR(1) mais plutôt VARCHAR(10485760). Le
comportement est maintenant complétement expliqué.

Attendez une seconde ! L’intention était de traiter des données CHAR(4) pas
de taille différente.

N’y a-t-il pas de solution ? Non, désolé… (à mois que…)

Plus loin dans la page de la documentation référencée ci-dessus, on peut lire
que argtype et rettype peuvent être de type base, composite, domain
ou même du type d’une table/colonne.

L’astuce est de créer un type composite ou un domain a utiliser en tant que
argtype et/ou rettype.

Voici quelques exemples:

-- Works in simple case trick\nSELECT test( '12345789'::char(4) );\n\n-- Domain trick\nCREATE DOMAIN c4 AS char(4);\nCREATE FUNCTION test(param c4)\nRETURNS c4\nAS $$\nBEGIN\n  RAISE NOTICE 'param=%', param;\n  RETURN param;\nEND;\n$$ LANGUAGE plpgsql;\n\nSELECT test( '123456789' );\nERROR:  value too long for type character(4)\n\nSELECT test( '123456789'::char(4) );\nNOTICE:  param=1234\n test \n------\n 1234\n(1 row)\n\nSELECT test( '123456789'::c4);\nNOTICE:  param=1234\n test \n------\n 1234\n(1 row)\n\nSELECT pg_typeof( test( '123456789'::char(4) ) );\nNOTICE:  param=1234\n pg_typeof \n-----------\n c4\n(1 row)

Le résultat obtenu devrait vous satisfaire.

Vous n’êtes pas satisfait ?

Je vous propose une dernière astuce.

-- Map a table structure\nCREATE TABLE qq ( c char(4));\n\nCREATE FUNCTION test(IN c qq, OUT d qq)\nLANGUAGE sql\nAS $$\nSELECT c;\n$$;\n\nSELECT * FROM test(ROW('12345'));\nERROR:  value too long for type character(4)\n\nSELECT * from test(ROW('1234'));\n  c   \n------\n 1234

Hmm, d’accord mais en quoi est-ce différent de l’utilisation d’un domain ?

-- Easy Type Alteration\nALTER TABLE qq ALTER c TYPE char(5);\n\nSELECT * FROM test( ROW('12345') );\n   c   \n-------\n 12345

Essayer de modifier un domain, vous verrez comme c’est simple et pas impactant (…).

L’astuce basée sur la définition de table permet de la flexibilité:

ALTER TABLE qq ADD ee int;\n\nSELECT test( ROW('12345', 4) );\n   test   \n----------\n (12345,4)\n\nSELECT * FROM test( ROW('12345', 4) );\n   c   | ee \n-------+----\n 12345 |  4

Nous espérons que vous avez apprécié cet article et que vous avez appris quelque chose de nouveau et d’intéressant.

\n", "date_published": "2024-12-02T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/bienvenue-sur-le-nouveau-blog-data-bene/", "url": "https://www.data-bene.io/fr/blog/bienvenue-sur-le-nouveau-blog-data-bene/", "title": "Bienvenue sur le nouveau blog de Data Bene", "content_html": "\n

Explorer PostgreSQL, l’Open Source et l’Innovation

Chez Data Bene, nous sommes ravis de vous présenter la nouvelle version de notre blog, où nous plongerons dans les sujets liés à PostgreSQL, aux technologies open source et aux tendances émergentes du marché. Grâce à cette mise à jour, nous avons pour ambition de vous offrir un contenu riche en analyses techniques, en actualités du secteur et en études de cas inspirantes.

Partisans convaincus des solutions open source, nous croyons fermement que PostgreSQL est un moteur d’innovation et d’efficacité pour les entreprises modernes. À travers nos articles et nos tutoriels, nous visons à permettre à nos lecteurs d’exploiter pleinement le potentiel de PostgreSQL. Nous aborderons nos fonctionnalités préférées et partagerons les dernières avancées de cet écosystème incontournable, des sujets qui, selon nous, vous aideront à tirer le meilleur parti de ce puissant système de gestion de bases de données relationnelles.

Dans un environnement technologique en constante mutation, l’open source s’impose comme le symbole de la collaboration, de l’innovation et du développement communautaire.

Pour cette raison, dans notre blog, nous explorerons :

  1. les outils open-source qui font partie de l’écosystème PostgreSQL,
  2. comment améliorer et soutenir la collaboration open-source, et
  3. des projets pour continuer à progresser dans les développements qui façonnent l’avenir des technologies ouvertes tout en évitant le verrouillage par les fournisseurs.

Avec des années d’expérience auprès d’une gamme variée d’entreprises, des startups émergentes aux entreprises mondiales, nous avons vu de première main comment les organisations innovantes utilisent PostgreSQL pour assurer leur succès. Notre blog mettra en vedette non seulement des idées d’entrepreneurs et de leaders technologiques partageant leurs expériences, mais aussi des articles approfondis de nos propres expertes et experts PostgreSQL. Ils discuteront de leurs fonctionnalités PostgreSQL préférées, des outils natifs, des défis rencontrés et de la manière dont ils les ont surmontés, offrant ainsi une perspective technique unique sur les défis du monde réel.

Nous explorerons également les tendances émergentes et les nouvelles technologies qui façonnent l’avenir de PostgreSQL, offrant un aperçu de la manière dont les startups et les entreprises établies naviguent dans l’évolution rapide de la gestion des données. Que ce soit par des interviews de fondateurs ou des analyses de projets innovants, nous mettrons en lumière comment PostgreSQL continue d’être un acteur clé de l’innovation dans le monde technologique d’aujourd’hui.

Enfin, chez Data Bene, la durabilité n’est pas qu’un mot à la mode — c’est une valeur fondamentale qui guide chacune de nos actions. Alors que nous nous engageons dans de nouvelles initiatives de développement et explorons les technologies de pointe, nous nous engageons à minimiser notre empreinte environnementale et à promouvoir des pratiques éco-responsables. De l’optimisation de l’efficacité des logiciels à la réduction de la consommation d’énergie, nous nous engageons à construire un avenir plus durable, ligne de code après ligne de code. Par conséquent, certains des articles que nous publierons mettront en avant ces pratiques et ouvriront la discussion sur la durabilité dans les pratiques de développement de PostgreSQL.

Nous vous invitons à nous rejoindre dans cette aventure passionnante d’exploration, de découverte et d’innovation. Que vous soyez un passionné de PostgreSQL, un défenseur de l’open source, un amateur de startups, un développeur expérimenté ou simplement curieux, il y en aura pour tous les goûts dans notre blog ! Alors, mettez cette page en favori, suivez-nous sur LinkedIn et gardez un œil sur notre prochaine newsletter. Où que vous nous suiviez, vous pourrez rester informé de nos mises à jour régulières remplies de précieuses idées et d’inspiration.

Merci de faire partie de notre communauté. Ensemble, continuons à grandir, apprendre et réussir.

\n", "date_published": "2024-09-25T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/data-bene-partenaire-du-pgday-paris-2023/", "url": "https://www.data-bene.io/fr/blog/data-bene-partenaire-du-pgday-paris-2023/", "title": "Data Bene partenaire du pgDay Paris 2023", "content_html": "\n

Comme chaque année Data Bene participe activement aux pgDays qui, nouveauté de cette année, seront sur deux jours. Évènement devenu incontournable pour tous les adeptes de PostgreSQL! Data Bene est “Partner” de cet événement qui vous donne la possibilité de vous former, de partager les expériences et de découvrir les dernières avancées, fonctionnalités de la base de données relationnelles open source.

Dans sa volonté de contribution, Data Bene participe aussi à la journée du 22 mars pour délivrer des Tutoriels (En Français):

Le matin, Frédéric Delacourt présentera «Tout ce que vous avez toujours voulu savoir sur les Pools de Connexions (sans jamais oser le demander)», de 9h à 12h15.

L’après-midi, ce sera au tour de Cédric Villemain avec «CREATE EXTENSION, la vôtre de préférence», de 13h45 à 17h.

Nous sommes ravis de pouvoir vous y accueillir. Vous trouverez le détails des formations sur l’agenda des 2 jours, et vous pourrez vous enregistrer sur la page inscription.

En espérant vous y voir nombreux !

L’équipe de Data Bene.

\n", "date_published": "2023-03-14T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/data-bene-partenaire-du-meetup-postgresql-geneve-cern-2022/", "url": "https://www.data-bene.io/fr/blog/data-bene-partenaire-du-meetup-postgresql-geneve-cern-2022/", "title": "Data Bene contribue au Meetup PostgreSQL@CERN 2023", "content_html": "\n

Data Bene est co-sponsor avec le CERN du Meetup organisé par le groupe d’utilisateurs de
PostgreSQL de Genève, le vendredi 13 Janvier après midi au CERN à Genève. Cédric et Hélène
serons heureux de vous y accueillir ou de vous compter parmi nous in situ ou via
le webcast: https://webcast.web.cern.ch/event/i1221200

Nous y animerons une conférence sur Citus Data: Base de donnée distribuée sans
complexe.

\n", "date_published": "2023-01-11T00:00:00Z" } ,{ "id": "https://www.data-bene.io/fr/blog/data-bene-partenaire-du-pgday-paris-2022/", "url": "https://www.data-bene.io/fr/blog/data-bene-partenaire-du-pgday-paris-2022/", "title": "Data Bene partenaire du pgDay Paris 2022", "content_html": "\n

Data Bene sera présent tout au long de la journée de 24 mars 2022 en temps que «Partner Sponsor» pour vous acceuillir à LA conférence de la communauté en France. Nous y animerons une conférence sur le partitionnement.

\n", "date_published": "2022-03-23T00:00:00Z" } ] }