Le blog Dalibo

Plongez dans le monde de CloudNativePG #13 - OOM Kill et QoS

Fri, 02 Oct 2026 00:00:00 -0500

Lyon, le 2 octobre 2026

CloudNativePG ou comment embarquer un éléphant sur un porte-conteneurs !

Il faut s’attendre à de nombreux changements lorsqu’une instance est déployée dans Kubernetes. L’une d’entre elles concerne la gestion de la mémoire et plus spécifiquement le mécanisme d’éviction en cas de surconsommation mémoire. Regardons cela de plus près !

Good old days

L’installation sur serveur physique ou machine virtuelle était, jusqu’à peu, la méthode privilégiée pour déployer PostgreSQL. Dans la majorité des cas, les machines utilisées étaient, et sont encore, dédiées à nos bases de données.

Une machine = une instance PostgreSQL. Le principe KISS à l’état pur.

Sur ces environnements dédiés, il est communément admis que la désactivation de la surallocation mémoire (paramètres vm.overcommit_memory et vm.overcommit_ratio) est une bonne pratique. La documentation officielle de PostgreSQL explique pourquoi. Pour les détails, voir notre base de connaissance.

Et maintenant ?

Les besoins évoluent et justifient parfois le déploiement de centaines, voire de milliers d’instances. Un environnement conteneurisé, et à fortiori un environnement Kubernetes, peut être le socle de la stack technique pour répondre à ce besoin.

Mais les règles du jeu changent :

La désactivation de l’overcommit memory n’est pas systématique, voire impossible (par exemple le mode CIS Hardening de RKE2 et le fichier rke2-cis-sysctl.conf);
Votre hébergeur ne vous laissera pas accéder aux Nodes pour faire de telles configurations ;
D’autres mécanismes du noyau rentrent en jeu (cgroups) ;
Vos bases de données peuvent cohabiter avec des Pods applicatifs ;
…

Tout cela pour dire qu’il faut revoir notre copie et adapter nos pratiques avec les possibilités offertes par Kubernetes.

QoS des Pods

Dans Kubernetes, il existe le concept de QoS. À chaque Pod est associée une classe de service qui, selon la configuration en ressources, modifie les règles de déploiement du Pod et est utilisée en cas d’éviction de Pods. L’idée de cet article n’est pas de détailler ce concept. Pour cela, nous vous renvoyons à la documentation officielle.

Ce qu’il faut savoir, c’est qu’il en existe trois qui sont attribuées selon les requests et limits que vous définissez sur la ressource Pod.

Best Effort ;
Burstable ;
et Guaranteed.

Selon la QoS, des ajustements sont faits au niveau des processus et la politique d’éviction change.

Surconsommation et OOM Killer

Sur un système Linux, si un processus consomme trop de mémoire, l’OOM Killer peut être appelé pour chercher à en libérer afin d’éviter de saturer le système. Le meilleur moyen de soulager le système est d’arrêter un programme en cours de fonctionnement… un arrêt que l’on pourrait qualifier de « brutal ».

L’OOM Killer sélectionne le processus à cibler en fonction d’un score calculé par le noyau. Pour faire simple, le processus avec le score le plus élevé est évincé. Il existe des moyens pour ajuster le score d’un processus en particulier.

L’OOM Killer n’a pas connaissance du traitement effectué par tel ou tel processus. Concrètement, avec PostgreSQL, il faut à tout prix éviter un kill du service postmaster, donc le rendre moins susceptible à être ciblé.

Trois Clusters, trois QoS et des comportements différents

Déployons trois Clusters avec des QoS différentes (dépend des requests et limits) et voyons quels sont les changements visibles. Notez qu’ici, la désactivation de l’overcommit n’a pas été faite.

cluster-besteffort :
- Pas de section resources ;

cluster-burstable :

  requests:
    memory: "300Mi"
    cpu: "50m"

cluster-guaranteed :

  requests:
    memory: "2Gi"
    cpu: "0.2"
  limits:
    memory: "2Gi"
    cpu: "0.2"

Regardons notamment les paramètres oom_score et oom_score_adj des processus PostgreSQL postmaster de chaque Cluster.

Cluster	oom_score	oom_score_adj
`cluster-besteffort`	1333	1000
`cluster-burstable`	1321	1000
`cluster-guaranteed`	3	-997

Pour information, voici une manière de trouver le pid du postmaster :
kubectl exec -it cluster-besteffort-1 -c postgres -- cat /var/lib/postgresql/data/pgdata/>postmaster.pid | head -n1
36

Ce qui ressort de ce tableau est que Kubernetes modifie les valeurs du oom_score_adj des processus (ici postmaster, mais ce serait pareil pour d’autres processus présents dans le Pod) en fonction de la QoS du Pod. Cela a pour conséquence de modifier le oom_score qui lui est calculé à partir de plusieurs paramètres (voir la formule) ajustée par oom_score_adj.

Ainsi, si ces trois Clusters sont sur un même Node Kubernetes et qu’une pression au niveau de la mémoire a lieu, le noyau fait appel à l’OOM Killer pour retrouver de la mémoire. Ce dernier cible donc en priorité un processus issu de cluster-besteffort ou cluster-burstable.

Là encore, il n’y a pas moyen de savoir ce que fait vraiment le processus ciblé et s’il est préférable d’arrêter tel ou tel processus parmi les cibles potentielles.

Avec PostgreSQL, on préférait que des processus enfants (par exemple un backend client) soient ciblés plutôt que postmaster. C’est possible avec la variable d’environnement PG_OOM_ADJUST_VALUE.

CloudNativePG en rajoute une couche

Ainsi, lors de la création d’un Cluster CloudNativePG qui a une QoS positionnée à guaranteed, l’opérateur effectue une opération supplémentaire en ajustant la variable d’environnement PG_OOM_ADJUST_VALUE à 0. Ceci est fait uniquement pour la QoS guaranteed.

postgres@cluster-guaranteed-1:/$ ps -aux
postgres    3749  0.0  0.0 226404 13200 ?        Ss   10:40   0:00 postgres: cluster-guaranteed: postgres postgres [local] idle
[...]
postgres    3890  0.0  0.0   6412  3768 pts/0    R+   10:48   0:00 ps -aux
postgres@cluster-guaranteed-1:/$ cat /proc/3749/oom_score_adj 
0
postgres@cluster-guaranteed-1:/$ cat /proc/3749/oom_score
666

Dans cet exemple, le backend client au pid 3749 a bien son score d’ajustement (oom_score_adj) à 0 et donc un oom_score bien plus élevé que postmaster, en l’occurrence, 666 (score généralement rencontré pour des processus consommant peu de mémoire).

OOM Killer en action

Comprendre pourquoi telle ou telle valeur est affectée et comment cela influence l’éviction de processus et de Pod est nécessaire. Mais concrètement, qu’est-ce que cela change dans ma vie de DBA, SRE ou DevOps ?

Faisons en sorte de déclencher une pression mémoire et observons ce qu’il se passe. Pour cela, exécutons l’ordre SQL de tri suivant en veillant à augmenter drastiquement la mémoire de travail utilisable. Il ne faut évidemment pas tenter ceci en production !

SET work_mem = '1000GB';
EXPLAIN (ANALYZE) SELECT i FROM generate_series (1,3e9) i ORDER BY i DESC ;

(Noter que le DBA n’a aucun moyen d’empêcher un utilisateur de faire cela !) Cet ordre est lancé dans chacun des trois Clusters via psql. Les traces sont remontées des traces noyau du système par sudo journalctl --utc -fke.

cluster-besteffort

Lors du test, le kube-controller a fait appel au OOM Killer du système car une allocation mémoire lui a été impossible.

kernel: kube-controller invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP)…

Un peu plus loin, le process ciblé est indiqué task=postgres,pid=613477. Il consommait environ 7,8 Go de mémoire (8176716kB). L’OOM Killer global a été invoqué : global_oom; car il s’agit d’une allocation impossible. Notez également que le oom_score_adj du processus tué se trouve mentionné à la fin de la ligne (1000).

kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=cri-containerd-e51b72c22b5f0f9bd976a36b7e33183d364d6562623c0eb8d1e68ee1eaa99321.scope,mems_allowed=0,global_oom,task_memcg=/system.slice/docker-0d3ac421a88f3823ef43f68cfc… ,task=postgres,pid=613477,uid=26
kernel: Out of memory: Killed process 613477 (postgres) total-vm:9011764kB, anon-rss:8176716kB, file-rss:160kB, shmem-rss:4308kB, UID:26 pgtables:16212kB oom_score_adj:1000

Le système a donc cherché, trouvé et arrêté un processus consommateur sur le Node : Killed process 613477 (postgres).

Détail qui a son importance, le processus était « rattaché » à d’autres processus. On peut notamment le voir avec le paramètre task_memcg (tronqué dans l’exemple de trace) et are going to be killed due to memory.oom.group set. La description faite dans le message du commit est très claire. L’idée est de traiter le cgroup comme une entité unique.

kernel: Tasks in /system.slice/docker-0d3ac421a88f3823ef43f68cfcad6de7739069b01ff51d2ed918f8659e93702e.scope/kubelet.slice/kubelet-kubepods.slice/kubelet-kubepods-besteffort.slice/kubelet-kubepods-besteffort-pod6e7d6a9d_2946_4aa6_9c74_c866aadf17e1.slice/cri-containerd-342c7d2864fbb3eed1c4645e39db632ae0d0ec41676780b6f6af047e252ab011.scope are going to be killed due to memory.oom.group set

Ces autres processus ne sont ni plus ni moins que ceux présents dans le conteneur, autrement dit, ceux associés au même cgroup… donc le postmaster lui-même.

kernel: Out of memory: Killed process 611483 (manager) …
kernel: Out of memory: Killed process 611551 (postgres) …
kernel: Out of memory: Killed process 611552 (postgres) …
kernel: Out of memory: Killed process 611553 (postgres) …
kernel: Out of memory: Killed process 611554 (postgres) …
kernel: Out of memory: Killed process 611555 (postgres) …
kernel: Out of memory: Killed process 611556 (postgres) …
kernel: Out of memory: Killed process 611557 (postgres) …
kernel: Out of memory: Killed process 611559 (postgres) …
kernel: Out of memory: Killed process 611560 (postgres) …
kernel: Out of memory: Killed process 611561 (postgres) …
kernel: Out of memory: Killed process 611562 (postgres) …
kernel: Out of memory: Killed process 613471 (psql) …
kernel: Out of memory: Killed process 613477 (postgres) …

Ce qui explique que le Pod a été redémarré. D’un point de vue PostgreSQL, on peut dire que l’instance a connu un crash. Elle redémarre donc en mode recovery. Dans les traces de PostgreSQL, lors du redémarrage, la ligne suivante est visible.

"message": "database system was not properly shut down; automatic recovery in progress

cluster-burstable

Lors du test sur le deuxième Cluster, les mêmes observations sont faites.

Un processus (ici python3) sur le Node demande de la mémoire.
Comme l’allocation ne peut pas être faite, ce même programme invoque l’OOM Killer. Le programme python3 qui tourne sur la machine, n’est pas responsable du manque de mémoire ;
Le processus ciblé est le processus PostgreSQL qui exécute le tri. Il consomme environ 8 Go de RAM , trop pour les capacités de la machine ;
Tous les processus du cgroup sont évincés ;
L’instance redémarre en mode recovery puis redevient accessible.

Ceci n’est pas surprenant, puisque nous avons vu que rien ne diffère d’un point de vue mémoire et sur la configuration oom_*.

cluster-guaranteed

Pour ce dernier cas, l’OOM Killer n’est pas invoqué par n’importe quel processus, mais par un processus postgres, processus interne au conteneur où est exécuté le tri.

kernel: postgres invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
kernel: CPU: 3 UID: 26 PID: 614252 Comm: postgres …

Notons le pid du processus : 614252.

On retrouve dans les traces la quantité de mémoire et la limite imposée atteint par le cgroup.

kernel: memory: usage 2097152kB, limit 2097152kB, failcnt 871

Cette limite correspond bien aux 2 Go indiqués dans la définition des resources du Cluster cluster-guaranteed. Le journal de traces remonte les processus en cours au moment de l’invocation de l’OOM Killer.

kernel: Tasks state (memory values in pages):
kernel: [  pid  ]   uid  tgid total_vm      rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
kernel: [ 577430]    26 577430      257        1        0        1         0    40960       10          -998 pause
kernel: [ 607179]    26 607179   347284     4631     4622        9         0   266240        0          -997 manager
kernel: [ 607224]    26 607224    56071     4675      643      428      3604   172032        0          -997 postgres
kernel: [ 607225]    26 607225    17249      640      638        2         0   118784        0             0 postgres
kernel: [ 607226]    26 607226    56104     1317      657        2       658   163840        0             0 postgres
kernel: [ 607227]    26 607227    56104      728      653        2        73   135168        0             0 postgres
kernel: [ 607228]    26 607228    56104      873      657        2       214   163840        0             0 postgres
kernel: [ 607229]    26 607229    56106     2172      669        2      1501   151552        0             0 postgres
kernel: [ 607230]    26 607230    56104     1278      655      209       414   143360        0             0 postgres
kernel: [ 607237]    26 607237    56104     1890      656      105      1129   139264        0             0 postgres
kernel: [ 607238]    26 607238    56472     1806      722      758       326   159744        0             0 postgres
kernel: [ 607239]    26 607239    56104     1021      656      264       101   131072        0             0 postgres
kernel: [ 607240]    26 607240    56472      939      716        2       221   143360        0             0 postgres
kernel: [ 614238]    26 614238     4002     1380      278     1102         0    73728        0          -997 psql
kernel: [ 614252]    26 614252   597541   514260   511082     2136      1042  4300800        0             0 postgres

En dernière ligne, on retrouve le processus 614252 à l’initiative de l’appel au OOM Killer. C’est ce processus qui consomme le plus de mémoire, un peu moins de 2 Go. Au passage, notez que tous les processus enfants à postmaster ont bien hérité du paramètre PG_OOM_ADJUST_VALUE à 0.

Le kill est initié, mais cette fois-ci avec une contrainte différente constraint=CONSTRAINT_MEMCG. Celle-ci indique que l’éviction d’un processus ne peut se faire que dans le conteneur en question. Ceci est logique : quel serait l’intérêt d’arrêter des processus en dehors de ce cgroup s’il est nécessaire de retrouver de la mémoire au sein de ce cgroup ?

sept. 21 06:52:05 lenovo-pro kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=cri-containerd-683…,mems_allowed=0,oom_memcg=/system.slice/docker-0d3ac421a88f3823ef43f68cfcad6de7739069b01ff51d2ed918f8659e93702e.scope/kubelet.slice/kubelet-kubepods.slice/kubelet-kubepods-pod34c24b1b_f063_4779_b778_1a490b0cab1b.slice,task_memcg=/system.slice/docker-0d3ac…e2eaa7.scope,task=postgres,pid=614252,uid=26

Le processus 614252 est donc arrêté.

kernel: Memory cgroup out of memory: Killed process 614252 (postgres) total-vm:2390164kB, anon-rss:2044328kB, file-rss:8544kB, shmem-rss:4168kB, UID:26 pgtables:4200kB oom_score_adj:0

Notez que le début de la ligne de trace diffère d’un OOM Kill global. Ici il s’agit d’un Memory cgroup out of memory alors que, dans les deux autres exemples, il s’agissait d’un Out of memory.

Là aussi, tous les processus du cgroup sont évincés comme memory.oom.group est utilisé. L’instance redémarre en mode recovery puis redevient accessible.

Par ailleurs, il est à noter que dans cet exemple, comme dans ceux d’avant, tous les processus redémarrent, postmaster compris. En effet, la disparition brusque d’un backend est suspecte et le processus principal préfère préserver l’intégrité des données en redémarrant tout. Là aussi, toutes les connexions autres qui pouvaient exister sont coupées brutalement et devront être re-initiées après le redémarrage de l’instance.

Une différence notable est à souligner. Vous l’avez peut-être compris, mais dans le cas d’un Cluster en QoS Guaranteed, la consommation RAM n’a pas pu dépasser les 2 Go (limits.memory), là où avec les autres QoS, la limite de consommation par le processus de tri a atteint les 8 Go. La consommation de 8 Go de RAM a eu pour conséquence d’épuiser les ressources du système qui étaient de 16 Go.

Conclusion

Nous l’avons vu, le déploiement de PostgreSQL sur Kubernetes implique des changements de fonctionnement à très bas niveau, notamment sur la gestion mémoire. Le diagnostic d’un out of memory dépend également de la QoS du Pod.

Cette QoS dépend directement de la configuration des ressources allouées à celui-ci. CloudNativePG gère une préconisation des développeurs de PostgreSQL en ce qui concerne le score d’ajustement oom_score_adj pour les processus enfants pour une QoS Guaranteed.

Plusieurs choses sont à retenir :

Si l’overcommit_memory du Node n’est pas désactivé, l’arrêt d’un processus postgres de type backend client aura pour conséquence l’arrêt et le redémarrage de l’instance, peu importe la QoS choisie. La QoS Guaranteed limite le risque d’un arrêt brutal de postmaster.
Cette même QoS vous permet de garder le contrôle sur la consommation mémoire du Pod ;
Et enfin, vous évitez une surconsommation qui pourrait avoir des effets de bord sur le reste du système. D’ailleurs, nous l’avons vu dans les exemples, les deux premiers appels OOM Killer ont été faits par deux outils sans rapport avec PostgreSQL qui se trouvaient sur le système : python3 et kube-controller.

Des questions, des remarques ?

** Écrivez-nous !**

Dalibo recrute un⋅e Administrateur/Administratrice Systèmes Senior

Tue, 29 Sep 2026 00:00:00 -0500

Paris, le 29 septembre 2026

Dalibo est à la recherche d’un⋅e Administrateur/Administratrice Systèmes Senior.

Le poste

Compte tenu de la taille de notre structure, votre rôle en tant qu’administrateur systèmes au sein de notre structure sera très polyvalent :

assurer la disponibilité, l’intégrité et la sécurité de nos services,
contrôler le matériel et l’inventaire informatique,
gérer les relations avec les fournisseurs, prestataires et clients concernant le SI de Dalibo,
accompagner et former des collègues dans leur utilisation de Linux et des services internes, en diffusant les bonnes pratiques de sécurité,
participer aux chantiers de mise en place ou de modification des outils et services informatiques.

Au moins un déplacement trimestriel à Paris est à prévoir, pour une durée d’une semaine.

Les compétences requises

Système et virtualisation : GNU/Linux, Proxmox, LXC, KVM
Sécurité réseaux : VPN, routage, firewall, gestion des accès
Automatisation : Ansible, Terraform ou OpenTofu
Outils collaboratifs et métier : Git / GitLab / GitHub, messageries instantanées, mail, ERP (Dolibarr)

Les « plus » significatifs

Gestion d’inventaire
Connaissance de l’offre Cloud de Scaleway

La connaissance exhaustive de tous les outils n’est pas un impératif. Il sera possible de se former au sein de l’équipe.

CLIQUEZ ICI POUR PLUS D’INFORMATIONS

Les avantages

Télétravail, possibilité de devenir sociétaire, grille salariale transparente, participation aux bénéfices, contributions aux communautés PostgreSQL et SCOP… Nous offrons un environnement favorable à la montée en compétences et à leur partage, à l’implication et l’émancipation des salarié⋅es, ainsi qu’au respect de la vie privée et familiale. Les détails sont ici.

Postuler

via Welcome to the Jungle
ou écrire à recrutement@dalibo.com.

À propos de Dalibo

DALIBO est le spécialiste français de PostgreSQL. Actuellement forte de 44 salarié⋅es, dont une majorité d’administrateurs de bases de données (DBA), la société propose un cursus de formation complet aux DBA, ainsi qu’une offre de support spécialement conçue pour s’adapter aux besoins des entreprises en matière de sécurité, performance et pérennité.

Libriste et SCOP

Depuis ses débuts, notre PME est engagée auprès de la communauté PostgreSQL en France comme à l’étranger. Non seulement à travers le développement logiciel, mais aussi en participant à des événements, en donnant des conférences libres d’accès, en sponsorisant des projets, etc.

Dalibo est avant tout un collectif passionné qui a inscrit, en 2011, les principes du Libre dans ses statuts coopératifs.

Formations Dalibo : le calendrier 2027

Thu, 24 Sep 2026 00:00:00 -0500

Saint-Étienne, le 24 septembre 2026

Administration, Développement, Performances et Transition vers PostgreSQL… Dalibo vous propose 10 formations pour vous accompagner dans votre montée en compétences. Voici les prochaines sessions, ainsi que le calendrier 2027. [mise à jour le 30 septembre]

Rappels utiles

Certifiées Qualiopi, nos formations sont détaillées sur dalibo.com/formations.

Inter-entreprises et en présentiel, elles durent 2 ou 3 journées.

Depuis 2020, certaines sessions sont également assurées à distance sur 4 ou 5 matinées, de 9h00 à 12h30.

Enfin, il est possible d’organiser des sessions en intra-entreprise, au sein de vos locaux.

Contact

Appelez Jill et Lorraine au + 33 1 83 64 61 88,
ou écrivez à formation@dalibo.com.

Le calendrier des sessions

Cursus Administration

DBA1 : Administration PostgreSQL

5-9 octobre 2026 - à distance
17-19 novembre 2026 - à Paris
4-8 janvier 2027 - à distance
9-11 mars 2027 - à Paris
26-30 avril 2027 - à distance
7-9 septembre 2027 - à Paris
6-10 décembre 2027 - à distance

DBA2 : Administration PostgreSQL Avancée

13-15 octobre 2026 - à Paris
30 novembre - 4 décembre 2026 - à distance
18-22 janvier 2027 - à distance
8-11 février 2027 - à Paris
6-8 avril 2027 - à Paris
14-18 juin 2027 - à distance
5-7 octobre 2027 - à Paris

DBA3 : Sauvegarde et Réplication avec PostgreSQL

24-26 novembre 2026 - à Paris
14-18 décembre 2026 - à distance
1-5 février 2027 - à distance
27-29 avril 2027 - à Paris
6-10 septembre 2027 - à distance
14-16 décembre 2027 - à Paris

HAPAT : Haute disponibilité avec PostgreSQL

1-3 décembre 2026 - à Paris
23-25 mars 2027 - à Paris
31 mai - 4 juin 2027 - à distance
21-23 septembre 2027 - à Paris
22-26 novembre 2027 - à distance

CNPG1 : PostgreSQL dans Kubernetes avec CloudNativePG

27-28 octobre 2026 - à Paris
19-22 janvier 2027 - à distance
6-7 avril 2027 - à Paris
5-6 octobre 2027 - à Paris
7-10 décembre 2027 - à distance

Cursus Performances

PERF1 : PostgreSQL Performances

13-15 octobre 2026 - à Paris
16-20 novembre 2026 - à distance
8-10 décembre 2026 - à Paris
4-8 janvier 2027 - à distance
27-29 avril 2027 - à Paris
31 mai - 4 juin 2027 - à distance
19-21 octobre 2027 - à Paris
13-17 décembre 2027 - à distance

PERF2 : Indexation et SQL Avancés

24-25 novembre 2026 - à Paris
15-18 décembre 2026 - à distance
9-10 février 2027 - à Paris
18-21 mai 2027 - à distance
28-29 septembre 2027 - à Paris
2-5 novembre 2027 - à distance

Cursus Développement

DEV1 : Initiation au langage SQL

16-17 mars 2027 - à Paris
1-3 juin 2027 - à Paris
7-9 septembre 2027 - à Paris
23-25 novembre 2027 - à Paris

DEVPG : Développer avec SQL

22-24 septembre 2026 - à Paris
23-25 mars 2027 - à Paris
15-17 juin 2027 - à Paris
21-23 septembre 2027 - à Paris
7-9 décembre 2027 - à Paris

Cursus Transition

DBAADM : Administration PostgreSQL pour DBA expérimentés

uniquement en intra-entreprise et en présentiel

Des questions, des remarques ?

Écrivez-nous à formation@dalibo.com.

Manuels Dalibo : sortie de la version 26.09

Tue, 15 Sep 2026 00:00:00 -0500

Saint-Étienne, le 15 septembre 2026

Les manuels Dalibo sont mis à jour tous les trimestres, toujours en libre accès sous format PDF, ePub et html. Voici les liens vers leur dernière version 26.09.

Les manuels

Comme annoncé dans l’article précédent, cette rentrée est marquée par l’arrivée de deux nouvelles formations :

CNPG1, pour apprendre à utiliser et déployer PostgreSQL dans Kubernetes avec CloudNativePG,
DEV1, pour s'initier au langage SQL.

Vous retrouverez les liens vers leurs manuels ci-dessous.

Administration

DBA1 - Administration PostgreSQL : PDF, ePub, html
DBA2 - Administration PostgreSQL Avancée : PDF, ePub, html
DBA3 - Sauvegarde et Réplication avec PostgreSQL : PDF, ePub, html
DBAADM - Administration PostgreSQL pour DBA expérimentés : PDF, ePub, html
HAPAT - Haute disponibilité avec PostgreSQL : PDF, ePub, html
CNPG1 - PostgreSQL dans Kubernetes avec CloudNativePG : PDF, ePub, html

Développement

DEV1 - Initiation au langage SQL : PDF, ePub, html
DEVPG - Développer avec SQL : PDF, ePub, html

Performances

PERF1 - PostgreSQL Performances : PDF, ePub, html
PERF2 - Indexation et SQL Avancés : PDF, ePub, html

Transition vers PostgreSQL

DBAADM - Administration PostgreSQL pour DBA expérientés : PDF, ePub, html

Rappels utiles

Revue des cours, nouveaux TP et quiz, correctifs… La mise à jour des manuels est assurée nos DBA, par ailleurs formateurs et consultants.

Les informations principales concernant les formations Dalibo sont ici.

Si vous notez des éléments qui demandent à être clarifiés, précisés, corrigés, vous pouvez nous écrire à formation@dalibo.com.

Les manuels sont publiés sous la licence CC BY-NC-SA qui autorise l’utilisation non commerciale, le partage dans les mêmes conditions et la modification, à condition de créditer Dalibo.

Le privilège des stagiaires

Ces manuels ne sont pas commercialisés. Cependant, en vous inscrivant à une formation Dalibo, vous recevrez un code pour commander gratuitement l’impression et la livraison à domicile de deux manuels de votre choix.

Des questions, des remarques ?

Écrivez-nous à formation@dalibo.com.

Formations Dalibo : découvrez CloudNativePG et SQL

Thu, 10 Sep 2026 00:00:00 -0500

Saint-Étienne, le 10 septembre 2026

La famille des formations Dalibo s’agrandit ! Nos DBA et développeurs en ont conçu deux nouvelles : CNPG1 pour découvrir l’opérateur Kubernetes CloudNativePG, et DEV1 pour s’initier au langage SQL.

CNPG1 : PostgreSQL dans Kubernetes avec CloudNativePG

Cette nouvelle formation destinée aux DBA et aux DevOps s’inspire du workshop déjà présenté en mars dernier (Cf. notre article).

Son objectif principal est de présenter l’utilisation et le déploiement de PostgreSQL dans Kubernetes avec l’opérateur CloudNativePG : création, configuration, supervision et mise à jour de clusters, politique de sauvegarde, haute disponibilité. Plus d’infos ici.

Prochaines sessions :

27-28 octobre 2026, à Paris
19-20 janvier 2027, à Paris
du 6 au 9 avril 2027, à distance

DEV1 : Initiation au langage SQL

Vous avez besoin d’acquérir ou d’améliorer vos compétences en SQL ?

Cette autre nouvelle formation vous permettra de comprendre le modèle relationnel et la structure d’un schéma, de savoir également comment ajouter, modifier, supprimer, extraire et sécuriser des données. Vous apprendrez également à écrire des requêtes SQL complexes. Plus d’infos ici.

Prochaines sessions :

du 2 au 4 février 2027, à Paris
du 1er au 3 juin 2027, à Paris

Rappels utiles

Certifiées Qualiopi, nos 10 formations sont détaillées sur dalibo.com/formations.

Elles se divisent en 4 cursus : Administration, Performances, Développement et Transition vers PostgreSQL.

Inter-entreprises et en présentiel, elles durent 2 ou 3 journées. Depuis 2020, certaines sessions sont aussi assurées à distance sur 4 ou 5 matinées, de 9h00 à 12h30.

Besoin d’un renseignement ? Vous souhaitez vous inscrire ? Appelez Jill et Lorraine au + 33 1 83 64 61 88, ou écrivez à formation@dalibo.com.

PostgreSQL Migrator 1.0 stable

Mon, 07 Sep 2026 00:00:00 -0500

Paris, le 7 septembre 2026

Après un an de bêta, Dalibo annonce PostgreSQL Migrator 1.0 stable.

PostgreSQL Migrator est un outil de conversion et de migration de base de données vers PostgreSQL. Nous souhaitons apporter un grand vent de modernisation dans ce domaine stratégique pour de nombreuses équipes. Cette version prend déjà en charge les systèmes Oracle et MySQL/MariaDB.

Vous souhaitez moderniser ou libérer vos données grâce à PostgreSQL ? PostgreSQL Migrator vous intéressera sûrement !

Fonctionnalités

PostgreSQL Migrator 1.0 profite de notre expertise reconnue dans la communauté. Plusieurs fonctionnalités en font un compagnon de choix dans vos chantiers de modernisation :

installation très simple,
inspection optimisée une fois pour toutes,
navigation efficace dans le projet de migration,
configuration TOML simple et extensible,
analyse syntaxique et transpilation de chaque bout de code dans votre modèle,
et transfert performant des données.

Pour cette version 1.0, l’inspection des objets est complète. PostgreSQL Migrator 1.0 sait convertir et migrer les rôles, les schémas, les séquences, les tables, les index et les contraintes. Pour la donnée, PostgreSQL Migrator sait migrer les données scalaires, JSON, LOB et convertir les colonnes booléennes.

Une interface efficace

Ce logiciel s’adresse aux DBA venant d’autres systèmes. La détection et la présentation des incompatibilités et des alternatives dans PostgreSQL sont une étape majeure pour envisager la migration. PostgreSQL Migrator propose une navigation efficace dans le modèle de base de données tant de la source — Oracle ou MySQL — que du futur modèle à créer dans PostgreSQL.

L’interface propose une navigation thématique ou hiérarchique, une recherche globale, des onglets et l’identification des blocages à la migration. Contrairement aux logiciels historiques de base de données, PostgreSQL Migrator offre une interface épurée et intelligente plutôt qu’une pléthore de boutons et de boîtes de dialogue. Le transfert se fait en ligne de commande.

Migration performante

Pour une copie très efficace, PostgreSQL Migrator réalise les transferts avec des instructions COPY uniquement. Nous sommes convaincus que les exports au format texte avec INSERT ou à l’aide des Foreign Data Wrapper ne seront jamais pertinents pour un chantier de migration. L’outil écrit les données d’entrée de la commande COPY au fur et à mesure de leur lecture depuis la source, même pour les LOB et autres grosses données.

Non seulement la consommation mémoire est stable sous les 500 Mo, mais PostgreSQL reçoit les données au plus tôt. Nos tests présentent un débit global 10 fois supérieur aux alternatives libres comme Ora2pg. Aucune extension n’est requise dans l’instance PostgreSQL cible.

PostgreSQL Migrator orchestre précisément les nombreuses tâches de création d’objet et de copie pour garantir la cohérence du processus de migration et l’utilisation optimale des ressources.

Stable et éprouvé

Malgré sa jeunesse, PostgreSQL Migrator offre une excellente stabilité. Le projet dispose d’une intégration continue exigeante et de méthodes de développement garantissant les non-régressions. Nous testons PostgreSQL Migrator sur des projets Open Source réels, pas seulement sur des petites bases de formation. D’ores et déjà, PostgreSQL Migrator a migré des bases de production. L’investissement qualité est réel et les premiers retours sont très concluants.

Libre et documenté

PostgreSQL Migrator est écrit en Go et ne dépend pas des bibliothèques propriétaires d’Oracle. Comme tous les logiciels Dalibo Labs, PostgreSQL Migrator est intégralement sous licence PostgreSQL. Pas de petites lignes en bas de page !

La page du projet propose un guide pour installer et essayer l’outil, la documentation de la configuration et de la ligne de commande, les fonctionnalités supportées et planifiées, l’actualité des développements.

Utiliser, contribuer

PostgreSQL Migrator 1.0 n’est que le premier jalon d’une longue feuille de route. Rapidement, PostgreSQL Migrator migrera les vues, les triggers et les partitions ; l’inspection et la transpilation sont déjà en place. Comme PostgreSQL lui-même, PostgreSQL Migrator implémente les fonctionnalités brique par brique avec le souci de la maintenabilité, de la stabilité et de la qualité.

Dalibo propose depuis longtemps une offre commerciale pour migrer vos bases les plus complexes depuis tous les SGBD concurrents. Une longue histoire de contributions illustre cette expertise : Ora2pg, data2pg, transqlate et maintenant PostgreSQL Migrator.

Beaucoup d’outils de migration sont propriétaires, Dalibo offre une contribution généreuse à la communauté.

Pour commencer dès maintenant, suivez le guide.

PostgreSQL Migrator 1.0 stable

Mon, 07 Sep 2026 00:00:00 -0500

Paris, September 7, 2026

After a year of beta, Dalibo announces PostgreSQL Migrator 1.0 stable.

PostgreSQL Migrator is a tool for converting and migrating databases to PostgreSQL. We aim to bring a strong breath of modernization to this strategic area for many teams. This release already supports Oracle and MySQL/MariaDB systems.

Do you want to modernize or free your data with PostgreSQL? PostgreSQL Migrator will surely be of interest to you!

Features

PostgreSQL Migrator 1.0 benefits from our recognized expertise within the community. Several features make it a companion of choice in your modernization projects:

very simple installation,
inspection optimized once and for all,
effective navigation through the migration project,
simple and tweakable TOML configuration,
parsing and transpilation of every piece of code in your model,
and high-performance data transfer.

For this 1.0 release, object inspection is complete. PostgreSQL Migrator 1.0 can convert and migrate roles, schemas, sequences, tables, indexes and constraints. For data, PostgreSQL Migrator can migrate scalar, JSON and LOB data and convert boolean columns.

An effective interface

This software is aimed at DBAs coming from other systems. Detecting and presenting incompatibilities and alternatives in PostgreSQL is a major step in considering a migration. PostgreSQL Migrator offers effective navigation through the database model, both of the source — Oracle or MySQL — and of the future model to be created in PostgreSQL.

The interface offers thematic or hierarchical navigation, a global search, tabs and the identification of migration blockers. Unlike legacy database software, PostgreSQL Migrator offers a clean and intelligent interface rather than a plethora of buttons and dialog boxes. Transfer is done using CLI.

High-performance migration

To achieve a very efficient copy, PostgreSQL Migrator performs transfers using COPY statements only. We are convinced that exports in text format with INSERT or using Foreign Data Wrappers will never be relevant for a migration project. The tool writes the input data of the COPY command as it is read from the source, even for LOBs and other large data.

Not only is memory usage stable below 500 MB, but PostgreSQL receives the data as early as possible. Our tests show an overall throughput 10 times higher than free alternatives like Ora2pg. No extension is required in the target PostgreSQL instance.

PostgreSQL Migrator precisely orchestrates the many object-creation and copy tasks to guarantee the consistency of the migration process and the optimal use of resources.

Stable and proven

Despite its youth, PostgreSQL Migrator offers excellent stability. The project has a demanding continuous integration and development methods that guarantee non-regression. We test PostgreSQL Migrator on real Open Source projects, not just on small training databases. PostgreSQL Migrator has already migrated production databases. The investment in quality is real and the first feedback is very conclusive.

Free and documented

PostgreSQL Migrator is written in Go and does not depend on Oracle’s proprietary libraries. Like all Dalibo Labs software, PostgreSQL Migrator is entirely under the PostgreSQL license. No fine print at the bottom of the page!

The project page offers a guide to install and try out the tool, the documentation for the configuration and the command line, the supported and planned features, and news about the developments.

Use, contribute

PostgreSQL Migrator 1.0 is only the first milestone on a long roadmap. Soon, PostgreSQL Migrator will migrate views, triggers and partitions; inspection and transpilation are already in place. Like PostgreSQL itself, PostgreSQL Migrator implements features brick by brick with a focus on maintainability, stability and quality.

Dalibo has long offered a commercial service to migrate your most complex databases from all competing DBMS. A long history of contributions illustrates this expertise: Ora2pg, data2pg, transqlate and now PostgreSQL Migrator.

Many migration tools are proprietary; Dalibo offers a generous contribution to the community.

To get started right now, follow the guide.

PostgreSQL : suivre son actualité avec nos newsletters

Tue, 18 Aug 2026 00:00:00 -0500

Saint-Étienne, le 18 août 2026

Pour Dalibo, j’édite et diffuse trois newsletters consacrées à des sujets d’actualité autour de PostgreSQL, dont les projets développés en interne, la vie communautaire et coopérative, les formations et les PGSessions de Dalibo.

Voici les principales caractéristiques de ces newsletters, et leur modalité d’abonnement.

Trois newsletters

Laura, chargée de communication et associée

Actualités PostgreSQL : mensuelle (sauf en été), elle reprend les derniers articles publiés sur ce blog-même. Les sujets abordés sont variés, ils concernent aussi bien PostgreSQL et ses logiciels satellites que les événements, les formations, et la vie coopérative de Dalibo. C’est la lettre d’info la plus « générale ».
Formation : moins fréquemment diffusée, celle-ci relaie surtout l’actualité des formations et workshops autour de PostgreSQL, dispensés par nos DBA consultants et formateurs. Vous y trouverez également les liens vers les manuels Dalibo - en libre accès - à l’occasion de leurs mises à jour.
PGSessions : à raison de 4-5 numéros par an, cette newsletter était jusqu’à présent réservée aux participants à la PGSession (avec leur accord explicite). Elle promeut notre événement annuel en communiquant essentiellement les prochaines dates, les modalités d’inscription et le programme, les vidéos en replay.

Pour vous abonner, écrivez-nous à communication@dalibo.com en précisant vos noms/prénoms, ainsi que la ou les newsletters qui vous intéressent.

Le logiciel utilisé

Afin d’améliorer nos pratiques en communication, nous avons choisi de migrer vers Sarbacane, une solution éditée par Positive Group France.

En effet, cette entreprise basée en France développe et maintient ses propres logiciels en interne.

Outre la conformité de ses services à la réglementation européenne, elle facilite également notre propre respect du RGPD en hébergeant les données de nos futures campagnes en Europe, chez OVH.

De notre côté, nous renonçons aux services de statistiques et de traçage, ainsi qu’à l’aide rédactionnelle de l’IA.

En communication, la sobriété est l’un des atouts qui facilite le respect des données personnelles.

Des questions, des remarques ?

Écrivez-nous à communication@dalibo.com.

Sortie de PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 et 19 bêta 3

Thu, 13 Aug 2026 00:00:00 -0500

Brive La Gaillarde, le 13 août 2026

Le PostgreSQL Global Development Group a publié le 13 août une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.6, 17.11, 16.15, 15.19, 14.24. Cette mise à jour corrige 28 vulnérabilités de sécurité et plus de 110 bugs. Cette mise à jour saute une version mineure de PostgreSQL 18, passant de la 18.4 à la 18.6. La version 18.5 n’a pas vu le jour suite à un problème de régression.

Après la mise à jour, trois points peuvent nécessiter des opérations supplémentaires décrites plus bas. Ce sont :

la création parallélisée des index GIN
btree_gist
ltree

Pour la liste complète, voir les Notes de version.

Annonce de fin de vie de PostgreSQL 14

PostgreSQL 14 ne recevra plus de mises à jour après le 12 novembre 2026. Si vous utilisez PostgreSQL 14 en production, nous vous conseillons de planifier une migration vers une version plus récente et supportée. Voir la politique de versionnement pour plus de détails.

Failles de sécurité

CVE-2026-6464: Un échec précoce de COPY FROM STDIN dans psql traite les lignes de données comme des commandes psql

CVSS v3.1 Base Score: 8.1
Versions vulnérables : 14 - 18.
L’inclusion de données non fiables dans la commande COPY de psql peut permettre à un administrateur du serveur de provoquer l’exécution de lignes de données en tant que commandes psql, via une injection d’erreur. Si la commande COPY FROM STDIN ou \copy FROM STDIN échoue avant que le serveur n’indique qu’il attend des lignes en entrée, psql traite les lignes de données intégrées au script comme des commandes psql. Un COPY FROM avec un nom de fichier n’est pas concerné. L’administrateur du serveur n’a pas de contrôle intrinsèque sur les lignes de données, une attaque complète nécessite donc que l’attaquant prenne le contrôle à la fois du serveur et des lignes à charger. Ou encore, un attaquant contrôlant uniquement ces lignes pourrait parvenir à ses fins à la faveur d’une erreur fortuite. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-6469: La commande ALTER TABLE ALTER TYPE réinitialise le propriétaire des statistiques étendues

CVSS v3.1 Base Score: 3.8
Versions vulnérables : 14 - 18.
Dans la commande ALTER TABLE ALTER TYPE, une affectation incorrecte du propriétaire réattribue à l’utilisateur courant la propriété des objets statistiques dépendants. Cela autorise à tort le propriétaire de la table à exécuter les commandes DROP STATISTICS et ALTER STATISTICS, et les interdit à tort au propriétaire précédent. La commande DROP TABLE reste capable de supprimer les objets statistiques, donc cette faille n’a aucun effet dans de nombreux cas de figure. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-6470: PostgreSQL ne vérifie pas le droit USAGE sur un type

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une autorisation manque dans les commandes DDL de PostgreSQL. Le créateur d’un objet peut alors créer une dépendance sur un type, et, via les commandes ALTER et DROP du type provoquer un déni de service. La plupart des opérations DDL vérifiaient bien ce droit, mais deux d’entre elles ne le faisaient pas : l’affectation d’un sous-type de range, et le référencement du type depuis une expression SQL. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-6471: Le décodage logique de PostgreSQL peut charger un fichier arbitraire via dlopen

CVSS v3.1 Base Score: 7.2
Versions vulnérables : 14 - 18.
Une autorisation est manquante dans le décodage logique de PostgreSQL. Un utilisateur non superutilisateur disposant du droit REPLICATION peut alors charger, via dlopen, n’importe quel fichier visible depuis le compte système sous lequel s’exécute le serveur, en choisissant le bon plugin de décodage logique, et ensuite d’exécuter du code arbitraire sous ce compte. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14662: Les types tsvector et tsquery sous-dimensionnent des allocations à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Dans les fonctions concernant les types de données tsvector et tsquery, un débordement d’entier permet à un utilisateur non privilégié de forcer le serveur à sous-dimensionner une allocation et à écrire hors limites, via des entrées volumineuses spécialement conçues. Il peut alors exécuter un code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Ces types proviennent généralement de la logique applicative et non des utilisateurs de l’application : une attaque menée par un utilisateur final en utilisant l’application comme relai est donc peu probable. La CVE-2026-6473 avait corrigé des problèmes similaires. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14663: pgcrypto chiffre et déchiffre silencieusement en clair pour les algorithmes de chiffrement désactivés par OpenSSL

CVSS v3.1 Base Score: 6.5
Versions vulnérables : 14 - 18.
Le stockage en clair opéré par pgcrypto pour les algorithmes de chiffrement désactivés permet aux utilisateurs de récupérer les données en clair, par lecture directe du texte chiffré défectueux. La version d’OpenSSL et sa configuration déterminent les algorithmes désactivés. Si l’application accepte des données chiffrées en entrée, le déchiffrement réussira même avec une mauvaise clé. Cela fait perdre la modeste protection apportée par le Modification Detection Code (MDC). Les fonctions concernées sont pgp_sym_encrypt, pgp_sym_decrypt, pgp_pub_encrypt, pgp_pub_decrypt, pgp_sym_encrypt_bytea, pgp_sym_decrypt_bytea, pgp_pub_encrypt_bytea et pgp_pub_decrypt_bytea. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14664: Un dépassement de heap buffer permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer dans le moteur d’expressions rationnelles de PostgreSQL permet à l’auteur d’une requête d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via un texte qui ne passerait pas la validation d’encodage. Ce problème est de la même famille que la CVE-2026-2006, mais il implique ici une croissance non prévue des données lors d’un aller-retour à travers pg_wchar. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14666: Le cache du row level security ignore les modifications des rôles

CVSS v3.1 Base Score: 4.2
Versions vulnérables : 14 - 18.
Le suivi des modifications d’appartenance à un rôle, des attributs de rôle et de la propriété des bases est incomplet. Une requête peut ainsi continuer à utiliser des règles de row level security mises en cache alors que ces changements imposent désormais d’autres règles, via la réutilisation du plan. Les politiques obsolètes restent en vigueur jusqu’à ce qu’un autre évènement invalide le cache ou que la session se termine. L’utilisateur peut alors réaliser des lectures et modifications encore récemment autorisées, mais désormais interdites. L’attaquant doit adapter son attaque au schéma de retrait de droits et aux politiques de sécurité propres aux rôles de l’application visée. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14668: Une confusion de type ctid dans l’estimation de sélectivité divulgue une dérivée de lecture arbitraire

CVSS v3.1 Base Score: 8.1
Versions vulnérables : 14 - 18.
À cause d’un mélange de type dans l’entrée de l’estimation de sélectivité du type ctid de PostgreSQL, le créateur d’un objet peut consulter un calcul dérivé de la valeur d’une portion arbitraire de 4 octets de la mémoire, via une entrée choisie qui n’est pas de type ctid. Bien que le calcul perde en précision, la récupération d’une part substantielle des valeurs en mémoire semble possible. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14669: Un dépassement de heap buffer dans to_char permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer dans to_char(timestamptz) permet à la partie qui choisit le fuseau horaire d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, en utilisant une abréviation de fuseau horaire POSIX long. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14670: Un dépassement de heap buffer sur les objets liés en plperl permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer au retour d’une table de hachage liée (tied hash) en plperl, le propriétaire d’une fonction spécialement conçue peut exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14671: Une confusion de type dans le cache de plans du module refint permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un mélange de types dans le module refint de PostgreSQL permet au créateur d’un objet d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Le correctif a débuté comme un rapport de bug non identifié comme problème de sécurité, et apparaît dans le dépôt git sous le sujet « refint: Remove plan cache. », sans numéro de CVE. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14672: Une différence de réponse observable avec un scram_iterations différent du défaut permet de deviner l’existence d’un utilisateur

CVSS v3.1 Base Score: 5.3
Versions vulnérables : 16 - 18.
Une différence de réponse observable dans l’authentification SCRAM de PostgreSQL permet à un utilisateur non authentifié de tester l’existence d’un utilisateur en observant le nombre d’itérations SCRAM. Cela suppose que l’utilisateur sondé ait un scram_iterations différent de la valeur par défaut, car la comparaison d’authentification pour un utilisateur inexistant renvoie la valeur par défaut. Parmi les versions majeures 16, 17 et 18, les versions mineures antérieures à PostgreSQL 18.5, 17.11 et 16.15 sont concernées. Les versions antérieures à PostgreSQL 16 ne sont pas concernées.

CVE-2026-14673: Le module amcheck de PostgreSQL ne réinitialise pas un search_path non fiable

CVSS v3.1 Base Score: 3.8
Versions vulnérables : 14, 15, 16 et 18.
Un search_path non fiable dans le module amcheck permet à un utilisateur disposant du droit EXECUTE sur les fonctions d’amcheck d’exécuter des fonctions arbitraires avec les droits des propriétaires des index d’expression qui dépendent du search_path. Un attaquant peut exploiter cette faille en positionnant un search_path malveillant avant d’appeler la fonction d’amcheck. Les versions antérieures à PostgreSQL 18.5, 16.15, 15.19 et 14.24 sont concernées. PostgreSQL 17 n’est pas concerné.

CVE-2026-14676: Un dépassement de heap buffer dans pg_stat_statements permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 18.
Un dépassement de heap buffer dans pg_stat_statements permet à l’auteur d’une requête d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via des requêtes spécialement conçues contenant des constantes de type array. Les versions antérieures à PostgreSQL 18.5 sont concernées. Les versions majeures antérieures à PostgreSQL 18 ne sont pas concernées.

CVE-2026-14677: pltcl et plperl en 32 bits sous-dimensionnent des allocations à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un débordement d’entier dans les versions compilées en 32 bits de pltcl et plperl permet au créateur d’un objet de forcer le serveur à sous-dimensionner une allocation et à écrire hors limites, via des fonctions spécialement conçues. Cela peut conduire à l’exécution de code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. La CVE-2026-6473 avait corrigé des problèmes similaires. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14678: La fonction picksplit de pg_trgm lit au-delà de la limite d’un tampon

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une lecture hors limites dans la fonction picksplit des index pg_trgm lit au-delà de la fin d’un heap buffer. Cela peut permettre au mainteneur d’une table de déduire certaines valeurs mémoire, via les imprécisions que constituent les choix de fractionnement d’index. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14679: Un dépassement de stack buffer lors de la correspondance des arguments écrit 0x0 et 0x1 dans la mémoire du serveur

CVSS v3.1 Base Score: 8.2
Versions vulnérables : 14 - 18.
Un dépassement de stack buffer lors de la mise en correspondance des noms d’arguments permet au créateur d’un objet d’obtenir des effets indéterminés, via le nombre de paramètres OUT. L’attaque ne peut écrire que les octets 0x0 et 0x1 dans la mémoire du serveur. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14680: Mélange de type via les arguments de type « internal »

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un mélange de types dans les arguments de type internal permet à n’importe quel utilisateur d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via des appels à des fonctions utilisant ce type d’argument. Le type internal représente une famille de structures de données mutuellement incompatibles, et non destinées à être manipulées depuis SQL. Le système censé empêcher de tels appels de fonction avait des failles. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-14681: Vérification incorrecte par PostgreSQL du chiffrement GSSAPI lorsqu’il est couplé à SSL

CVSS v3.1 Base Score: 4.2
Versions vulnérables : 17 - 18.
Une vérification incorrecte de l’intégrité des messages dans le support GSSAPI de PostgreSQL permet à un utilisateur de procéder à une négociation GSSAPI en dépit des règles du pg_hba.conf, en passant d’abord par une connexion TLS directe. Bien que le pg_hba.conf semble imposer GSSAPI, la connexion peut échanger des données par TLS uniquement. Si les réglages TLS sont plus permissifs que les réglages GSS, la connexion peut se poursuivre avec un niveau de protection moindre. Parmi les versions majeures 17 et 18, les versions mineures antérieures à PostgreSQL 18.5 et 17.11 sont concernées. Les versions antérieures à PostgreSQL 17 ne sont pas concernées.

CVE-2026-15741: La désérialisation d’expressions autorise une injection SQL via un argument d’EXTRACT

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Une faille d’injection SQL dans l’analyse (deparse) dans EXTRACT() permet au propriétaire d’un objet d’exécuter du code SQL arbitraire en tant que superutilisateur, via une définition d’objet hostile. La faille touche largement les consommateurs de cette reconstruction d’expressions, dont pg_dump, la commande \sf de psql et les usages similaires dans des outils tiers. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-15742: fuzzystrmatch écrit à des adresses arbitraires, à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un débordement d’entier dans le module fuzzystrmatch permet à un utilisateur de diriger des écritures vers une très large plage d’adresses, et donc d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données, via des entrées extrêmes fournies aux fonctions levenshtein() ou levenshtein_less_equal(). Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-16238: Un mélange de types dans pg_restore_attribute_stats() permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 18.
Un mélange de types dans la fonction pg_restore_attribute_stats() permet au créateur d’un objet d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Il peut profiter d’une confusion entre valeurs de type range et multirange lors de la restauration des statistiques d’attribut. Les versions antérieures à PostgreSQL 18.5 sont concernées. Les versions majeures antérieures à PostgreSQL 18 ne sont pas concernées.

CVE-2026-16239: Une confusion de type lors d’un CLOSE + DECLARE de curseur permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un mélange des types dans le cycle de vie des portal/curseurs permet à un utilisateur d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. L’exploitation passe par la recréation d’un curseur, ou d’un autre portal, avec des types différents. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-16241: Un dépassement négatif d’entier dans ECPG peut faire planter le client

CVSS v3.1 Base Score: 3.8
Versions vulnérables : 14 - 18.
Un dépassement négatif d’entier dans ECPG permet à un administrateur du serveur de base de données d’obtenir un déni de service temporaire du client ECPG, en envoyant une valeur bytea dépourvue du préfixe obligatoire. Le client écrase alors une très large zone mémoire avec des octets qui échappent à la connaissance et au contrôle de l’attaquant. Cela produit généralement un simple SIGSEGV, mais dans de rares cas, cela pourrait avoir un impact sur l’intégrité du client via cette écriture. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-18024: La fonction ascii() lit au-delà de la limite d’un tampon

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une lecture hors limites dans la fonction SQL ascii() permet à un utilisateur de divulguer jusqu’à 3 octets situés après la fin d’une allocation donnée, via une valeur texte spécialement conçue. Il s’agit de la même classe de bugs que celle corrigée par la CVE-2026-2006, mais avec un impact moindre. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-18408: La commande \unrestrict de psql permet au superutilisateur du serveur d’origine d’un pg_dump d’exécuter du code arbitraire dans le client psql

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
L’inclusion de données non fiables dans pg_dump permet à un superutilisateur malveillant du serveur d’origine d’injecter du code arbitraire, exécuté au moment de la restauration sous le compte système exécutant psql, via l’expansion des arguments de la méta-commande \restrict de psql. Le correctif de la CVE-2025-8714 avait introduit \restrict et \unrestrict pour bloquer cette attaque, mais \unrestrict suffisait à lui seul à la mener. Sont concernés pg_dump, pg_dumpall et pg_restore lorsqu’il est utilisé pour produire une sauvegarde au format plain. Un usage tiers de \restrict pourrait être affecté, mais aucun usage de ce type n’a été identifié. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

CVE-2026-19385: Un dépassement de heap buffer dans pg_dump permet l’exécution de code arbitraire

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de heap buffer dans pg_dump, lié à une trop longue liste de transformations de fonctions, permet à un créateur d’objet d’exécuter du code arbitraire en tant qu’utilisateur système exécutant pg_dump, via une liste de transformations malveillante. Les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24 sont concernées.

Correctifs et améliorations

Cette mise à jour corrige plus de 110 bugs reportés au cours des derniers mois.

Le problème suivant ne concerne que PostgreSQL 14, 15 et 16, mais nous le mettons en avant ici en raison de sa gravité :

Correction d’un auto-verrouillage (self-deadlock) pouvant survenir lors du rejeu de WAL générés par une version mineure antérieure. Cette régression, introduite dans la précédente série de versions mineures, pouvait bloquer une instance standby suivant une instance primaire dans une version mineure plus ancienne.

Les correctifs suivants concernent PostgreSQL 18. Beaucoup d’entre eux s’appliquent également aux autres versions supportées.

Correction de la construction parallélisée des index GIN afin que la valeur reltuples de la table soit correctement mise à jour dans pg_class. Auparavant, un worker parallèle pouvait remonter un nombre de lignes non initialisé, laissant reltuples à une valeur aberrante (dont Infinity ou NaN). Une telle valeur peut empêcher l’autovacuum et l’autoanalyze de traiter la table, et la situation ne se corrige pas d’elle-même. Si vous avez des tables avec des index GIN, vérifiez que leur reltuples est cohérent après la mise à jour. Voir la section « Mettre à jour ».
Plusieurs correctifs pour les index btree_gist, dont la gestion des NaN pour les types float4/float8, qui pouvait donner des résultats erronés sur les colonnes contenant des NaN et le tri correct des valeurs bit/bit varying lors de la construction de l’index. Une réindexation sur les colonnes de type float ou bit peut être nécessaire après la mise à jour. Voir la section « Mettre à jour ».
Correction d’un débordement d’entier dans les comparaisons ltree. Les valeurs ltree comportant plus de 14 653 labels environ pouvaient être comparées incorrectement, avec pour conséquence un index B-tree corrompu. Une réindexation des index affectés peut être nécessaire après la mise à jour. Voir la section « Mettre à jour ».
Correction du partition pruning pour les tables partitionnées par RANGE, afin que la partition DEFAULT ne soit plus ignorée alors qu’elle doit être parcourue. Auparavant, des lignes pouvaient manquer dans les résultats de requête.
Plusieurs correctifs pour les tables partitionnées avec des tables distantes (foreign-table) comme partition : lorsque l’élagage des partitions à l’exécution déterminait que certaines partitions n’avaient pas à être parcourues, les requêtes en cours vers les serveurs distants n’étaient pas toujours gérées correctement, provoquant des échecs.
Plusieurs correctifs sur RETURNING avec OLD et NEW.
Amélioration des performances des hash join lorsqu’il y a plusieurs clés de jointure et de nombreuses valeurs NULL.
Plusieurs correctifs du planificateur qui pouvaient produire des résultats erronés, notamment pour les tests valeur IN (tableau) où le tableau peut être vide, et pour les fonctions de fenêtrage COUNT() avec une clause EXCLUDE ou dépourvues d’ORDER BY.
Ajout des vérifications manquantes sur la « hachabilité » des comparaisons d’égalité pour les types conteneurs (array, composite types et ranges). Sans ces vérifications, le planificateur pouvait choisir un plan basé sur le hachage qui échouait ensuite à l’exécution avec l’erreur « could not identify a hash function ».
Correction de l’attachement de partitions d’index qui sont des contraintes d’exclusion, ce qui corrige aussi la sauvegarde et la restauration des contraintes d’exclusion partitionnées.
Correction de REINDEX CONCURRENTLY sur un index supportant une contrainte d’unicité différée, qui pouvait provoquer de fausses violations de contrainte.
Rétablissement d’une optimisation de parcours d’index qui convertit un motif LIKE ou une expression rationnelle à correspondance exacte en une condition d’égalité sur l’index, lorsque les collations de l’index et de l’expression diffèrent.
Plusieurs correctifs sur jsonpath : les opérateurs @? et @@ lèvent désormais correctement une erreur pour une variable non définie dans l’expression du chemin. Auparavant, ces opérateurs ne pouvant pas fournir de valeur de variable, une variable non définie était traitée comme un null JSON au lieu de produire une erreur, ce qui pouvait aussi entraîner une consommation mémoire non bornée.
Garantie du blocage de l’accès aux tables temporaires des autres sessions, qui pouvait conduire à des résultats silencieusement incorrects.
Correction des erreurs "no empty local buffer available" lors de l’accès à des tables temporaires, un effective_io_concurrency élevé pouvant permettre à un seul flux de lecture de consommer tous les buffers locaux.
L’autovacuum ne traite plus les bases dans le mauvais ordre, à savoir la plus faible priorité d’abord au lieu de la plus forte.
Rétablissement du mode failsafe de VACUUM contre le wraparound, afin qu’il utilise l’intégralité du pool de shared buffers comme prévu, ce qui ralentissait les vacuums d’urgence.
Correction d’un décodage possiblement incorrect des entrées d’index lors des index-only scans GiST et SP-GiST, qui pouvait renvoyer des données corrompues.
Correction d’une race condition dans la détection de conflits en niveau d’isolation SERIALIZABLE. Un conflit pouvait être manqué lors de l’examen d’un index B-tree initialement vide, laissant des transactions en conflit être validées, rompant au passage la sérialisabilité.
Correction de la journalisation dans les WAL des opérations qui effacent des bits dans les visibility maps des tables. Cela pouvait produire des sauvegardes incrémentales incorrectes ou laisser des écritures de pages partielles non corrigées.
Correction du décodage logique des transactions préparées vides. Une transaction préparée sans changement décodable pouvait envoyer un COMMIT PREPARED ou un ROLLBACK PREPARED au plugin de sortie sans PREPARE préalable, ce qui casse la réplication pour l’abonné natif.
Plusieurs correctifs sur libpq, dont la garantie que tous les octets en attente dans le tampon de déchiffrement SSL ou GSS sont bien consommés lors de la lecture des données, évitant qu’un client n’attende des données déjà arrivées.
Correction de pg_createsubscriber pour qu’il nettoie les objets laissés sur le publieur après un échec, y compris un slot de réplication.
Correction de pg_restore avec --statistics ou --statistics-only pour que, combiné à d’autres options de restauration sélective comme --schema, il restaure bien les objets attendus, conformément au comportement de pg_dump.

Cette mise à jour intègre également les données de fuseaux horaires tzdata 2026c : l’Alberta (America/Edmonton) passera à UTC-06 toute l’année (soit un horaire d’été permanent) à partir de novembre 2026, avec l’hypothèse que l’abréviation de fuseau sera CST à partir de cette date (cela pourrait changer). Le Maroc (Africa/Casablanca) passera quant à lui à UTC+00 permanent, sans changement d’heure, le 20 septembre 2026.

Mettre à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Pour appliquer la mise à jour, comme pour les autres versions mineures, les utilisateurs n’ont pas besoin de sauvegarder et recharger leur base de données, ni d’utiliser pg_upgrade. Vous pouvez simplement arrêter PostgreSQL et mettre à jour ses binaires.

Si vous avez des tables comportant des index GIN, nous vous recommandons de vérifier leur valeur reltuples après la mise à jour. Un bug dans la construction parallélisée des index GIN a pu laisser reltuples à une valeur aberrante (dont Infinity ou NaN) qui empêche définitivement l’autovacuum et l’autoanalyze de traiter la table. La requête suivante liste les tables possédant un index GIN, avec leur reltuples courant :

SELECT DISTINCT t.oid::regclass, t.reltuples
  FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
 WHERE t.relhasindex AND ic.relam = 2742;

Pour toute table dont la valeur reltuples semble incorrecte, exécutez un ANALYZE dessus (ou créez un autre index) pour réinitialiser la valeur.

Si vous utilisez btree_gist, vous devez réindexer les index btree_gist sur les colonnes float4 ou float8 susceptibles de contenir des valeurs NaN, ainsi que les index btree_gist sur des colonnes bit ou bit varying, par exemple :

REINDEX INDEX nom_de_votre_index;

Si vous utilisez ltree et que vous avez des index btree sur des valeurs ltree comportant un très grand nombre de labels (plus de 14 653 environ), vous devez réindexer ces index, car ils peuvent être corrompus, par exemple :

REINDEX INDEX nom_de_votre_index;

Les utilisateurs ayant sauté une version mineure ou plus peuvent avoir besoin de réaliser d’autres opérations post-mise à jour. Voir les Notes de version pour les détails.

À propos de la bêta de PostgreSQL 19

Cette version marque la troisième beta de PostgreSQL 19. Dans l’esprit de la communauté open source PostgreSQL, nous vous encourageons vivement à tester les nouvelles fonctionnalités de PostgreSQL 19 sur vos systèmes pour aider à éliminer bugs et autres problèmes. Nous ne conseillons pas d’exécuter PostgreSQL 19 Beta 3 en production, mais plutôt de trouver des moyens de faire tourner vos charges applicatives habituelles sur cette version bêta. Pour en savoir plus, voir le processus de test des versions beta.

Parmi les changements depuis la bêta 2 :

Retrait de GROUP BY ALL.
Plusieurs correctifs sur la nouvelle syntaxe FOR PORTION OF des tables temporelles.
Plusieurs correctifs sur la nouvelle fonctionnalité de synchronisation des séquences en réplication logique, dont une race condition impliquant REFRESH SEQUENCES.
Correction d’une erreur « unexpected logical decoding status change » pouvant survenir lorsque le décodage logique est activé de manière concurrente.
Correction de problèmes liés aux changements de propriétaire des abonnements.
Correction de résultats de requête erronés avec postgres_fdw, lors d’un push down d’une comparaison de tableau comme champ = ANY($1) impliquant une conversion de type implicite.
Correction d’un plantage lors des vérifications de clé étrangère impliquant une contrainte UNIQUE acceptant les valeurs nulles.
Correction du parsing par pg_plan_advice des tirets bas (underscore) dans les littéraux numériques.
Correction d’une clause FORMAT manquante lors de la reconstruction textuelle de JSON_ARRAY(query).

Pour la liste complète des nouvelles fonctionnalités et des changements, voir les notes de version] :

https://www.postgresql.org/docs/19/release-19.html

Tests des bugs et de la compatibilité

La stabilité de chaque version de PostgreSQL dépend grandement de vous, la communauté, pour tester la version à venir avec vos charges applicatives et vos outils de test, afin de trouver les bugs et les régressions avant la disponibilité publique de PostgreSQL 19. S’agissant d’une bêta, des changements mineurs de comportement de la base de données, de détails de fonctionnalités et d’API restent possibles. Vos retours et vos tests aideront à déterminer les derniers ajustements des nouvelles fonctionnalités, alors n’hésitez pas à tester rapidement. La qualité des tests réalisés par les utilisateurs détermine quand la version finale pourra être publiée.

Une liste des sujets en cours est disponible publiquement sur le wiki PostgreSQL. Vous pouvez signaler des bugs via ce formulaire sur le site de PostgreSQL :

https://www.postgresql.org/account/submitbug/

Liens

Si vous avez des corrections ou des suggestions concernant cette annonce de version, merci de les envoyer à la liste de diffusion publique pgsql-www@lists.postgresql.org (mailing list).

Dalibo recrute : Développeur/Développeuse backend

Thu, 30 Jul 2026 00:00:00 -0500

Paris, le 30 juillet 2026

Dalibo est à la recherche d’un Développeur ou Développeuse backend Python/Go/Rust en full remote.

Le poste

Au sein de l’agence Projets et développement, vous intégrerez l’équipe de développement logiciel en charge d’assurer les évolutions et la maintenance de nos outils d’industrialisation et de gestion de parc d’instances PostgreSQL.

Dans le cadre de ce poste, vous collaborez au quotidien avec :

des DBAs industrialisation et un chef de projet chargé de l’intégration des solutions chez nos clients ;
des Product Owners chargés de spécifier et recetter les User Stories, ainsi que de prioriser les objectifs et d’établir la feuille de route des solutions ;
des développeurs Python, Golang, Rust et frontend ;
le directeur technique.

Bien que le poste soit full remote, au moins un déplacement trimestriel à Paris est à prévoir, pour une durée d’une semaine.

Les compétences requises

Ce poste requiert la connaissance et l’expérience des domaines suivants :

GNU/Linux (Debian et base Redhat)
Packaging (Debian et base Redhat)
Niveau avancé dans deux des languages de programmation suivants : Python, Golang, Rust
Git : versionnement, collaboration sur des projets avec GitLab ou GitHub, et utilisation des pipelines CI pour l’intégration continue
Anglais écrit

Les compétences souhaitées

Connaître les domaines et outils suivants :

environnement et opérateurs Kubernetes, en particulier CloudNativePG
pglift
PostgreSQL et son écosystème

Une expérience dans le chiffrement, l’anonymisation et l’architecture logicielle serait également un “plus”.

Les avantages

Télétravail, possibilité de devenir sociétaire, grille salariale transparente, participation aux bénéfices, contributions aux communautés PostgreSQL et SCOP…

Nous offrons un environnement favorable à la montée en compétences et à leur partage, à l’implication et l’émancipation des personnes salariées, ainsi qu’au respect de la vie privée et familiale.

Les détails sont ici.

Postuler

via WelcomeToTheJungle,
ou écrire à recrutement@dalibo.com.

À propos de Dalibo

DALIBO est le spécialiste français de PostgreSQL. Actuellement forte de 42 salarié⋅es, dont une majorité d’administrateurs de bases de données (DBA), la société propose un cursus de formation complet aux DBA, ainsi qu’une offre de support spécialement conçue pour s’adapter aux besoins des entreprises en matière de sécurité, performance et pérennité.

Libriste et SCOP

Depuis ses débuts, notre PME est engagée auprès de la communauté PostgreSQL, non seulement à travers le développement logiciel, mais aussi en participant à des événements, en donnant des conférences libres d’accès, en sponsorisant des projets, etc.

Dalibo est avant tout un collectif passionné qui a inscrit, en 2011, les principes du Libre dans ses statuts coopératifs.