Un projet sur PostgreSQL n’a plus rien d’un choix marginal. En quelques années, la base est passée du statut d’outsider à celui de leader. Elle a dépassé des solutions que l’on pensait indétrônables et s’impose désormais partout : dans le cloud, dans les projets data, dans les architectures modernes. Et les chiffres sont difficiles à ignorer.
Sur GitHub, l’Octoverse observe une hausse nette du nombre de contributeurs entre 2024 et 2025. L’écosystème PostgreSQL progresse également dans les projets Python, Typescript et Go. C’est aujourd’hui l’un des environnements open source les plus actifs.
La tendance se confirme dans l’enquête Stack Overflow 2024 : PostgreSQL arrive en tête des bases utilisées par les développeurs. Près d’un répondant sur deux l’adopte au quotidien, avec une proportion encore plus élevée chez les professionnels.
DB-Engines raconte la même histoire. Dans le Top 4, PostgreSQL est la seule base qui reste stable entre 2024 et 2025. Oracle, MySQL et SQL Server enregistrent un recul visible sur la période. Pendant ce temps, PostgreSQL ne flanche pas.
En peu de temps, PostgreSQL est passé de choix discret à évidence technique. C’est devenu le premier réflexe des développeurs et, progressivement, le choix rationnel des DSI. Cette bascule ne s’explique pas par une seule qualité du projet : elle reflète un mouvement plus profond, où tout le marché des bases de données a commencé à se rééquilibrer.
PostgreSQL était l’outsider
Dans le monde d’avant, c’est-à-dire autour de 2012, PostgreSQL était mal positionné. MySQL dominait le web open source. Il était plus petit, plus simple, plus compact, et suffisait largement. C’était le choix naturel des CMS PHP comme WordPress ou Drupal.
Les entreprises se répartissaient alors entre deux blocs. D’un côté OracleDB, souvent lié à un ERP et à un écosystème Java. De l’autre SQL Server, installé au cœur des environnements Microsoft et .NET.
Dans ce contexte, PostgreSQL n’était pas le favori. On le jugeait plus lourd, plus austère. Ce n’était pas le choix des hobbyistes. Et pour un site web ou un SaaS en construction, personne n’avait vraiment besoin de PostgreSQL. On pouvait monter un produit complet sans jamais le croiser.
La dynamique change dès 2018. Cette année-là, 33 % des développeurs déclarent utiliser PostgreSQL dans l’enquête Stack Overflow. Et le projet apparaît pour la première fois dans le haut de classement DB-Engines.
Entre 2018 et 2025, tout s’accélère. Et c’est là que le basculement s’opère.
Les développeurs apprennent PostgreSQL par défaut
Depuis 2023, on peut déjà constater que PostgreSQL est le seul du Top 5 qui ne s’effondre pas. Snowflake et Databricks progressent, mais ils sont surtout positionnés sur des usages Big Data ou IA. Leur croissance se fait surtout au détriment des bases historiques, plus orientées ERP ou applicatif.
Les trois leaders d’hier reculent tous en même temps. MySQL perd du terrain. SQL Server aussi. Oracle encore plus. Et ce mouvement n’est pas anodin. Je vous explique les raisons de cette bascule dans la deuxième partie.
DB Engines mesure la popularité d’un SGBD en observant son volume de mentions sur internet. Le score dépend du nombre de questions postées sur les forums, des discussions sur les réseaux sociaux, ou encore des occurrences dans les offres d’emploi.
Pour performer sur ce tableau, les éditeurs produisent de plus en plus de contenu. Cela renforce mécaniquement leur présence dans les sources analysées. Et c’est pour cela qu’il est essentiel de compléter cette lecture avec d’autres études.
Sur Stackoverflow, PostgreSQL l’emporte franchement.
Et la question est plus directe : “Avec quelles bases de données avez-vous travaillé cette année ?”.
Résultat :
* PostgreSQL : 55,6 %
* MySQL : 40,5 %
* SQLite : 37,5 %
* Microsoft SQL Server : 30,1 %
* Redis : 28,0 %
* MongoDB : 24,0 %
* MariaDB : 22,5 %
* Elasticsearch : 16,7 %
* Oracle : 10,6 %Et si on filtre pour avoir uniquement les développeurs professionnels, PostgreSQL monte même à 58%, en grappillant des points à un peu tout le monde.
La différence avec DB Engines est flagrante. Oracle et SQL Server sont des éditeurs avec de lourds moyens marketing. Ce qui leur permet de rester en tête sur DB Engines. Mais pas forcément de prendre la tête sur Stackoverflow.
L’indicateur de Stackoverflow montre aussi que les nouveaux projets, les nouveaux développements sont fait sur PostgreSQL. Ce qui indique que le SGBD open-source va continuer à progresser dans le classement.
Il faut noter que les développeurs parlent principalement de bases de données applicatives. C’est normal qu’ils ne parlent pas d’une base de données qui est embarquée avec un ERP le plus souvent.
Sur Github, la communauté de contributeurs est vibrante !
Github publie l’Octoverse qui fait un paysage des projets open-source les plus actifs de l’année.
MySQL y est devenu un fantôme depuis le rachat par Oracle. Et MariaDB qui est le fork open-source est en perte de vitesse.
PostgreSQL présente 229 “principal authors”, c’est-à-dire des contributeurs qui ont au moins un commit.
La communauté compte 463 personnes et a grandi de 103 personnes en 2024.
66% des lignes de code sont attribuées à 18 contributeurs. La Core Team compte 7 personnes qui sont salariées d’entreprises comme Entreprise DB, Crunchy mais aussi Microsoft.
Ce mode de gouvernance rassure les entreprises. Contrairement à d’autres logiciels open source, il n’a pas vraiment de sponsor. Ce sont les géants de la tech qui y contribuent en salariant les core-contributeurs. Je vous explique pourquoi tout de suite.
Les raisons de l’adoption massive de PostgreSQL.
Pour justifier cette adoption massive, il y a en premier lieu la gouvernance que je vais développer juste après, mais aussi un jeu de fonctionnalités très adapté aux besoins actuels des entreprises. Et le soutien massif des hyperscale.
Gouvernance : personne ne peut le racheter.
C’est l’une des principales peurs des DSIs.
Ils se sont retrouvés coincés, en 2008, quand Oracle a racheté Java et MySQL impactant les licences libres. Et dans le même temps, Oracle a changé ses pratiques commerciales sur ses licences et les factures sont devenues plus qu’imprévisibles.
À l’époque, la Communauté Européenne avait bloqué le rachat. Et ça s’était conclu après plusieurs mois de lutte avec une autorisation sous condition : MySQL doit rester disponible en licence libre GPL jusqu’en 2015. Le texte mentionne même l’objectif de migration vers PostgreSQL pour les entreprises qui veulent rester sur une base de données libre.
PostgreSQL c’est un pot commun. Différentes grandes entreprises dont Microsoft salarient les contributeurs. Et ils influencent ainsi les fonctionnalités qui sont implémentées. Et tout le monde peut bloquer un rachat prédateur.
PostgreSQL a toutes les extensions à la mode.
Comme les entreprises envoient leurs salariés pour contribuer à PostgreSQL, il a rapidement de suite les fonctionnalités dont elles ont besoin.
Un des top of minds c’est PostGIS, qui s’est imposé comme un leader sur le geospatial.
TimescaleDB pour les timeseries. `pgvector` pour faire des RAGs et soutenir les usages IA/LLM.
Postgresql permet de mélanger JSON et relationnel proprement avec JSONB + GIN. Il aura également une full-text search intégrée et customisable que les petits SGBD comme MySQL n’ont pas.
Il a aussi des systèmes d’index qui marchent mieux sur des gros jeux de données.
Foreign Data Wrappers permet d’utiliser votre vieille DB oracle, un Kafka, un S3, comme si c’était une base dans votre propre table. Ça permet de créer une vue, de recouper des données ou de faire une migration progressive.
Et tout ça c’était des features qu’il fallait souvent acheter en plus chez Oracle ou un SGBD qui n’est pas open-source et libre.
Elle a tout ce dont les entreprises ont besoin.
En combinant l’offre de service d’un fournisseur Cloud et le produit logiciel open-source, les grandes entreprises retrouvent tout ce qui faisait le succès des bases de données propriétaires.
1 – De la haute disponibilité
Ils avaient ça avec Oracle et des clusters VMware. Ils vont pouvoir le retrouver chez AWS avec la base de données RDS, une gestion multi-AZ et un failover géré par AWS.
2 – Scalabilité
Avant ils devaient ajouter des serveurs Oracle, modifier le VMware. Et à chaque palier négocier les licences. Avec AWS ou un autre Cloud Provider ils pourront changer de taille d’instance, ajouter des replicas etc… sans renégocier.
3 – Performance stable
Les entreprises peuvent être très intenses sur leurs bases de données. Et elles sont souvent un goulot d’étranglement en termes de performance. Toutes les applications de l’entreprise utilisent la même base de données ? Il suffit qu’elle soit chahutée et tous les systèmes informatiques sont perturbés.
Avant ils sur-provisionnaient des gros serveurs, c’était toute une ingénierie de bien répartir Oracle dessus. Et le stockage SAN c’est assez onéreux.
Chez le Cloud provider du coin ils pourront avoir un produit de PostgreSQL haute performance : Aurora chez AWS, Alloy chez GCP. Et tout sera managé.
4 – Sécurité et conformité
Oracle avait bien toutes les fonctionnalités et VMware apportait du cloisonnement. Dans le Cloud, on utilisera l’IAM du fournisseur, on mettra en place du chiffrement KMS. Un argument de vente d’Oracle était de permettre des certifications de sécurité comme le HDS ou le SOC2 plus facilement. C’est possible avec un hébergeur bien sélectionné et une base PostgreSQL.
Le Move2Cloud en quelques chiffres.
Cette année, c’est Atlassian qui a migré 4 millions de bases de données. De PostgreSQL sur RDS à Aurora qui est le produit haut de gamme chez AWS. Notion communique également sur le sharding de base de données PostgreSQL. Instagram continue d’optimiser son PostgreSQL depuis 2020.
L’URSSAF raconte même chez Republik IT comment ils ont migré d’Oracle à PostgreSQL.
Et surtout, Supabase, Neon, Timescale, Render : tous ces outils pour développer des applications embarquent PostgreSQL dès la première ligne de code, déployés sur AWS, GCP ou Azure.
Aujourd’hui AWS occupe 30 à 32% du marché mondial PaaS/IaaS, Azure détient 20 à 25% et Google Cloud Platform représente un peu plus de 10 pourcents (Canalys / Omdia).
En tant que développeur, est-ce que j’ai besoin d’apprendre à utiliser PostgreSQL ?
La question se pose, parce qu’on pourrait penser qu’avec les ORM et autres connecteurs logiciels avec des bases de données, on n’a même plus besoin d’apprendre le SQL.
Sauf que beaucoup de problèmes de performances commencent dans la base de données. Et j’ai pu voir des développeurs Java qui se retrouvent bloqués sur des postes, malgré d’excellentes expériences sur Spring, parce qu’ils ne connaissaient pas correctement le rôle de JPA et Hibernate.
Pour tirer le meilleur de la base de données, on doit faire des choses un peu spécifiques côté logiciel. On propose sur WeLoveDevs tout une batterie de QCMs concernant les différents SGBD dont PostgreSQL, MongoDB et Elasticsearch. Et ce n’est pas que les DBA qui doivent s’y intéresser.
Utiliser PostgreSQL comme un SGBD orienté document.
C’est un peu contre-intuitif, mais on peut avoir le meilleur du SQL et NoSQL en utilisant les fonctionnalités JSON de PostgreSQL. Et ça c’est une logique cognitive à développer. Je vous recommande d’essayer de le faire par vous-même sur un projet à part pour bien comprendre le sujet.
Si vous aviez un MongoDB sur un petit projet, vous pouvez tenter une migration.
Migrer un site web de MySQL à PostgreSQL
Il y a une forte résistance des CMS PHP sur ce sujet aujourd’hui. WordPress ne supporte toujours pas correctement PostgreSQL par exemple. Il est fortement attaché à MySQL et MariaDB.
Vous avez peut-être un site web en PHP/MySQL. Il faut essayer de le migrer vers PostgreSQL. On pourrait imaginer que ça va être plus lourd parce que PostgreSQL demande plus de ressources. Mais c’est plus une croyance limitante qu’une réalité.
Faites votre prochain side project avec Node et PostgreSQL
Je me suis beaucoup amusé récemment avec Fastify et Handlebars. Vu que c’est un site complètement côté serveur, pas besoin de Supabase ou de Websocket. J’ai donc tout branché sur PostgreSQL directement.
Vous pouvez essayer avec un projet Next.JS également.
Franchement, un projet avec PostgreSQL c’est découvrir plein de fonctionnalités qui vous paraissaient inutiles avant, et indispensables ensuite.
Bonne expérimentation !
