Un moteur peut gagner des utilisateurs parce qu’il est rapide, fiable, moins cher ou simplement installé par défaut quelque part. PostgreSQL a aussi bénéficié d’un mécanisme plus étrange : des produits qui ne sont pas PostgreSQL ont intérêt à se comporter comme PostgreSQL.

CockroachDB annonce parler son protocole réseau. Des services cloud vendent de la compatibilité Postgres comme une caractéristique centrale. Des pilotes, ORM, outils d’administration et bibliothèques construits pour PostgreSQL deviennent ainsi une porte d’entrée vers d’autres systèmes.37

Michael Stonebraker, qui a lancé le projet POSTGRES à Berkeley, pousse l’idée encore plus loin. Dans un entretien publié par The Register le 19 août 2026, il estime qu’Oracle a involontairement aidé PostgreSQL en conservant MySQL après le rachat de Sun, poussant une partie du marché à chercher une alternative indépendante.9

C’est son interprétation de l’histoire, pas une causalité qu’on peut mesurer proprement quarante ans après les premiers travaux. Mais elle pointe vers quelque chose de plus solide : PostgreSQL n’est plus seulement un logiciel. Il est devenu une surface de compatibilité.

Et cette surface vaut peut-être autant que certaines fonctions du serveur lui-même.

Le mauvais vainqueur

POSTGRES n’a pas commencé avec SQL.

Le projet de Berkeley démarre en 1986 autour d’une ambition différente : dépasser Ingres et rendre la base extensible. L’équipe veut pouvoir ajouter des types, fonctions, opérateurs et méthodes d’accès sans reconstruire tout le système à chaque nouveau besoin.12

Joseph Hellerstein, qui a travaillé sur le projet, décrit cette extensibilité comme sa signature. Les travaux sur les types abstraits cherchent notamment à faire entrer dans une base des objets qui ne se résument pas à des nombres et des chaînes : données géométriques, structures utiles à la CAO, nouveaux index et fonctions définies par les utilisateurs.2

Puis le projet universitaire s’arrête avec la version 4.2. Andrew Yu et Jolly Chen reprennent le code et ajoutent un interpréteur SQL en 1994. Postgres95 apparaît, puis PostgreSQL en 1996.1

Ce détail est énorme.

La technologie originale de Stonebraker reste dans le moteur, mais la langue visible devient celle que le reste de l’industrie utilise déjà.

PostgreSQL n’a donc pas gagné en demandant au monde d’apprendre son dialecte historique. Il a accepté une interface commune, puis a continué à devenir étrange derrière cette interface.

Parler SQL

On résume souvent la compatibilité à SQL. C’est trop simple.

Deux bases peuvent accepter SELECT, JOIN et INSERT tout en divergeant dès qu’une application utilise les types, les transactions, les fonctions, les extensions ou les comportements précis de PostgreSQL.

Mais SQL fournit tout de même la première couche. Une équipe qui connaît déjà le modèle relationnel et l’écosystème SQL n’arrive pas dans un monde totalement neuf.

La seconde couche est plus discrète : PostgreSQL expose un protocole client/serveur documenté. La documentation de PostgreSQL 18 décrit aujourd’hui la version 3.2 du protocole frontend/backend, tout en conservant la compatibilité avec la version 3.0 utilisée depuis PostgreSQL 7.4.3

Le port 5432 n’est donc pas seulement un numéro que l’on finit par mémoriser après avoir mal configuré Docker trois fois. Il matérialise une interface stable entre le serveur et tout ce qui veut lui parler.

Le fil 5432

C’est là qu’une base peut profiter de PostgreSQL sans être PostgreSQL.

CockroachDB le documente explicitement : son serveur prend en charge le protocole PostgreSQL et la majorité de la syntaxe PostgreSQL, ce qui permet à beaucoup de pilotes, ORM et outils conçus pour Postgres de fonctionner avec lui.7

Pour un nouvel acteur, l’intérêt est évident. Créer un moteur est déjà assez compliqué. Recréer en plus un pilote Python, un pilote Go, un connecteur JDBC, un adaptateur pour chaque ORM, des plugins d’administration et dix ans de tutoriels serait une manière assez créative de se fabriquer une seconde montagne.

Parler Postgres permet d’emprunter une partie de la première.

Ce n’est pas une exclusivité de CockroachDB. The Register cite aussi YugabyteDB et Timescale dans cette famille de produits qui construisent autour de l’interface ou de l’écosystème PostgreSQL.8

Le point important n’est pas leur liste exacte. C’est le renversement économique : un concurrent peut augmenter la valeur de l’écosystème Postgres en choisissant d’être compatible avec lui.

Chaque nouvel outil compatible donne une raison supplémentaire aux bibliothèques et aux développeurs de considérer les conventions PostgreSQL comme un choix par défaut raisonnable. Puis cette familiarité rend la prochaine compatibilité encore plus intéressante.

Un standard commence souvent comme ça : pas parce qu’un comité l’a déclaré gagnant, mais parce que changer de langue coûte plus cher que continuer à la parler.

Compatible, pas identique

Cette idée devient dangereuse si on saute une étape.

CockroachDB lui-même publie une longue page de différences. Certaines fonctionnalités PostgreSQL ne sont pas prises en charge, d’autres se comportent différemment, et la documentation précise qu’un système distribué ne peut pas reproduire facilement toutes les sémantiques du serveur d’origine.7

Donc pgwire n’est pas un certificat magique de substitution.

Une application simple peut souvent réutiliser son pilote. Une application qui dépend d’un type spécifique, d’un verrou, d’une extension, d’une fonction système ou d’une subtilité transactionnelle peut découvrir que « compatible » signifie surtout « suffisamment proche pour commencer la conversation ».

C’est précisément pour cela qu’il faut séparer les couches.

Le protocole ouvre l’écosystème client, le dialecte réduit le coût d’apprentissage et la sémantique décide si l’application se comporte réellement de la même manière. Quant aux extensions, elles peuvent rendre une installation PostgreSQL très différente d’un serveur qui accepte simplement les mêmes messages réseau.

PostgreSQL pousse cette dernière couche très loin. Sa documentation permet d’ajouter fonctions, agrégats, types, opérateurs, classes d’opérateurs et paquets d’extensions. Ce principe existait déjà dans le projet de Berkeley, même si l’implémentation moderne a énormément évolué.2

La compatibilité attire vers le centre. L’extensibilité permet ensuite au centre de rester assez large pour ne pas exploser au premier nouveau besoin.

Personne ne possède

Une interface commune ne suffit pas si tout le monde craint qu’un fournisseur puisse la reprendre demain.

PostgreSQL possède ici un avantage structurel assez rare.

Sa licence est permissive, proche des licences BSD ou MIT. Elle autorise l’utilisation, la copie, la modification et la distribution, y compris dans des produits commerciaux, sous des obligations très légères.4

Le projet n’est par ailleurs pas la propriété d’une entreprise. Il possède bien une gouvernance : Core Team, committers, équipes d’infrastructure, sécurité et différents comités.5 L’absence de propriétaire unique ne signifie donc pas absence de décisions ou absence de pouvoir.

La FAQ officielle formule la distinction plus franchement : PostgreSQL est un projet communautaire et aucune société ne le contrôle.6

Cela change le calcul d’un produit qui choisit une compatibilité.

Adopter une API propriétaire, c’est accepter qu’un autre acteur puisse changer le prix, la licence, les conditions d’accès ou la direction du produit. Adopter une interface communautaire et permissive ne supprime pas tous les risques, mais réduit au moins celui d’un propriétaire unique qui décide que la porte d’entrée appartient finalement à son business model.

Stonebraker décrit dans The Register PostgreSQL comme un logiciel qui « n’appartient à personne » au sens commercial, repris après Berkeley par des programmeurs sans affiliation unique.8 La formule romantise un peu la réalité actuelle, puisqu’il existe une gouvernance et des entreprises très présentes parmi les contributeurs. Mais la propriété du projet reste distribuée.

Et cette distribution aide la compatibilité à paraître durable.

Le produit invisible

On raconte volontiers le succès d’un projet open source avec une liste de fonctionnalités.

Pour PostgreSQL, ce serait tentant : JSON, recherche, réplication, types, index, extensions, performances. Tout cela compte.

Mais une partie de sa force vit ailleurs. Elle tient dans ce que d’autres peuvent réutiliser sans demander la permission : une syntaxe familière, un protocole documenté, des pilotes présents partout, une licence permissive, des extensions et une gouvernance qui n’est pas attachée à un seul vendeur.

C’est un produit invisible, parce qu’il n’apparaît pas dans une capture d’écran.

Il apparaît quand une nouvelle base décide que son chemin le plus court vers les développeurs consiste à comprendre le protocole PostgreSQL. Il apparaît quand un outil d’administration fonctionne sans adaptation majeure. Il apparaît quand une équipe peut changer de moteur sans réécrire immédiatement toute sa couche d’accès aux données.

La leçon vaut bien au-delà de PostgreSQL.

Un projet peut essayer de garder chaque morceau de valeur à l’intérieur de ses frontières. Ou il peut rendre certaines de ses interfaces tellement utiles, stables et peu risquées à adopter que des tiers construisent dessus, autour, parfois même contre lui.

La seconde stratégie donne moins de contrôle.

Mais quand vos concurrents trouvent rentable de parler votre langue, vous avez peut-être fabriqué quelque chose de plus durable qu’une fonction de plus dans la prochaine release.