Découvrez les idées clés de Michael Stonebraker (Ingres, Postgres, Vertica) et comment elles ont façonné les bases SQL, les moteurs analytiques et les architectures de données d’aujourd’hui.
Michael Stonebraker est un informaticien dont les projets n’ont pas seulement influencé la recherche sur les bases de données : ils ont directement façonné les produits et les modèles de conception que de nombreuses équipes utilisent au quotidien. Si vous avez utilisé une base relationnelle, un entrepôt analytique ou un système de streaming, vous avez bénéficié d’idées qu’il a contribué à prouver, construire ou populariser.
Ce n’est pas une biographie ni un tour académique de la théorie des bases de données. Il relie plutôt les systèmes majeurs de Stonebraker (comme Ingres, Postgres et Vertica) aux choix que vous observez dans les stacks de données modernes :
Une base moderne est tout système capable de façon fiable de :
Différentes bases optimisent ces objectifs différemment—surtout quand on compare applications transactionnelles, tableaux de bord BI et pipelines temps réel.
Nous nous concentrerons sur l’impact pratique : les idées qui apparaissent aujourd’hui dans le monde « warehouse + lake + stream + microservices », et comment elles influencent vos achats, vos constructions et vos opérations. Attendez-vous à des explications claires, des compromis et des implications concrètes—pas à des démonstrations mathématiques approfondies.
La carrière de Stonebraker se comprend plus facilement comme une séquence de systèmes construits pour des tâches précises—puis les meilleures idées ont migré vers les produits mainstream.
Ingres a commencé comme un projet académique prouvant que les bases relationnelles pouvaient être rapides et pratiques, et pas seulement théoriques. Il a contribué à populariser les requêtes de type SQL et la pensée d’optimisation basée sur le coût qui est ensuite devenue normale dans les moteurs commerciaux.
Postgres (le système de recherche qui a donné PostgreSQL) a exploré une autre hypothèse : les bases ne doivent pas être à fonction fixe. Il doit être possible d’ajouter de nouveaux types de données, de nouveaux index et des comportements plus riches sans réécrire tout le moteur.
Beaucoup de fonctionnalités « modernes » remontent à cette époque : types extensibles, fonctions définies par l’utilisateur et une base capable de s’adapter aux changements de charge.
Avec la croissance de l’analytique, les systèmes orientés lignes peinaient sur les grands scans et agrégations. Stonebraker a défendu le stockage en colonnes et les techniques d’exécution associées, visant à lire seulement les colonnes nécessaires et à bien les compresser—des idées maintenant standard dans les bases analytiques et les entrepôts cloud.
Vertica a porté les idées de stockage en colonnes vers un moteur SQL MPP (massivement parallèle) commercialement viable, conçu pour de grandes requêtes analytiques. Le schéma se répète : un prototype de recherche valide un concept ; un produit le durcit pour la fiabilité, les outils et les contraintes clients.
Les travaux ultérieurs ont porté sur le traitement de flux et les moteurs spécifiques à des charges—argumentant que rarement une base polyvalente l’emporte partout.
Un prototype teste rapidement une hypothèse ; un produit doit prioriser l’opérabilité : mises à jour, monitoring, sécurité, performances prévisibles et support. L’influence de Stonebraker se voit parce que de nombreuses idées prototypes ont « gradué » pour devenir des capacités par défaut dans des bases commerciales plutôt que des options de niche.
Ingres (abréviation de INteractive Graphics REtrieval System) fut la preuve précoce que le modèle relationnel pouvait dépasser l’élégance théorique. À l’époque, beaucoup de systèmes reposaient sur des méthodes d’accès personnalisées et des chemins de données spécifiques aux applications.
Ingres voulait résoudre un problème simple et orienté business :
Comment permettre aux utilisateurs de poser des questions flexibles sur les données sans réécrire le logiciel à chaque fois ?
Les bases relationnelles promettaient que vous pouviez décrire ce que vous voulez (par ex. « clients en Californie avec factures impayées ») plutôt que comment le récupérer étape par étape. Mais tenir cette promesse nécessitait un système capable de :
Ingres fut une étape majeure vers cette version « pratique » du calcul relationnel—une solution qui tournait sur le matériel de l’époque et restait réactive.
Ingres a aidé à populariser l’idée qu’une base doit faire le travail difficile de planifier les requêtes. Plutôt que d’obliger les développeurs à tuner chaque accès, le système pouvait choisir des stratégies : quelle table lire en premier, quels index utiliser, comment joindre les tables.
Cela a favorisé la diffusion de la pensée SQL : quand vous pouvez écrire des requêtes déclaratives, vous itérez plus vite et davantage de personnes peuvent poser des questions directement—analystes, équipes produit, finance—sans attendre des rapports sur mesure.
L’idée pratique majeure est l’optimisation basée sur le coût : choisir le plan de requête avec le « coût » attendu le plus faible (généralement un mélange d’I/O, CPU et mémoire), en s’appuyant sur des statistiques des données.
Cela signifie souvent :
Ingres n’a pas inventé chaque élément de l’optimisation moderne, mais a aidé à établir le modèle : SQL + un optimiseur permet aux systèmes relationnels de passer de « bonne idée » à outil quotidien.
Les premières bases relationnelles supposaient souvent un ensemble fixe de types (nombres, texte, dates) et d’opérations (filtrer, joindre, agréger). Cela fonctionnait—jusqu’à ce que les équipes commencent à stocker de nouveaux types d’informations (géographie, logs, séries temporelles, identifiants métier) ou aient besoin de fonctionnalités de performance spécialisées.
Avec un design rigide, chaque nouveau besoin devient un mauvais choix : forcer les données dans des blobs texte, greffer un système séparé, ou attendre que le fournisseur ajoute le support.
Postgres a promu une idée différente : une base doit être extensible—c’est-à-dire que vous pouvez ajouter de nouvelles capacités de façon contrôlée, sans briser la sécurité et la cohérence attendues du SQL.
En clair, l’extensibilité ressemble à l’ajout d’accessoires certifiés à un outil électrique plutôt qu’au remontage complet du moteur. Vous apprenez de « nouveaux tours » à la base tout en conservant transactions, permissions et optimisation comme un tout cohérent.
Cet état d’esprit apparaît nettement dans l’écosystème PostgreSQL d’aujourd’hui (et dans de nombreux systèmes inspirés de Postgres). Plutôt que d’attendre une fonctionnalité cœur, les équipes adoptent des extensions validées qui s’intègrent proprement au SQL et aux outils opérationnels.
Exemples courants :
L’essentiel est que Postgres a traité « changer ce que la base sait faire » comme un objectif de conception, et cette idée influence encore l’évolution des plateformes de données modernes.
Les bases ne servent pas seulement à stocker l’information : elles doivent garantir que l’information reste juste, même quand beaucoup d’opérations se produisent simultanément. C’est le rôle des transactions et du contrôle de concurrence, et c’est une raison majeure pour laquelle les systèmes SQL sont devenus dignes de la confiance des entreprises.
Une transaction est un groupe de changements qui doivent réussir ou échouer comme une unité.
Si vous transférez de l’argent, passez une commande ou mettez à jour un stock, vous ne pouvez pas vous permettre des résultats « à moitié finis ». Une transaction garantit que vous n’aurez pas une commande débitée sans réservation de stock, ou un stock réduit sans commande enregistrée.
Concrètement, les transactions apportent :
La concurrence signifie que de nombreuses personnes (et applications) lisent et modifient les données en même temps : paiements clients, agents support modifiant des comptes, jobs en arrière-plan, analystes lançant des rapports.
Sans règles soignées, la concurrence crée des problèmes comme :
Une approche influente est MVCC (Multi-Version Concurrency Control). Conceptuellement, MVCC conserve plusieurs versions d’une ligne pendant un court laps de temps, de sorte que les lecteurs voient un instantané stable pendant que des écrivains effectuent des mises à jour.
Le grand avantage est que les lectures bloquent moins souvent les écritures, et les écrivains ne sont pas constamment ralentis par les requêtes longues. Vous conservez la correction tout en réduisant l’attente.
Les bases d’aujourd’hui servent souvent des charges mixtes : fortes écritures applicatives et lectures fréquentes pour tableaux de bord, vues clients et analytique opérationnelle. Les systèmes SQL modernes s’appuient sur des techniques comme MVCC, des verrous intelligents et des niveaux d’isolation pour équilibrer vitesse et correction—vous pouvez ainsi monter en charge sans sacrifier la confiance dans les données.
Les bases orientées lignes étaient conçues pour le traitement transactionnel : beaucoup de petites lectures/écritures, généralement sur un seul client, une seule commande, un seul compte. Ce design est excellent quand il faut récupérer ou mettre à jour tout un enregistrement rapidement.
Imaginez un tableur. Un stockage par lignes ressemble à classer chaque ligne dans son propre dossier : quand vous voulez « tout sur la commande #123 », vous sortez un dossier et c’est fini. Un stockage par colonnes classe par colonnes : un tiroir pour « order_total », un autre pour « order_date », un autre pour « customer_region ».
Pour l’analytique, vous avez rarement besoin de tout le dossier—vous posez généralement des questions comme « Quel a été le chiffre d’affaires par région le trimestre dernier ? » Cette requête touche peut-être quelques champs sur des millions d’enregistrements.
Les requêtes analytiques :
Avec le stockage en colonnes, le moteur peut lire seulement les colonnes citées dans la requête, en sautant le reste. Lire moins de données depuis le disque (et moins faire transiter en mémoire) est souvent le gain de performance majeur.
Les colonnes ont souvent des valeurs répétitives (régions, statuts, catégories). Elles se compressent donc bien—et la compression accélère l’analytique parce que le système lit moins d’octets et peut parfois opérer directement sur les données compressées.
Les stockages en colonnes ont marqué la transition des bases centrées OLTP vers des moteurs axés analytique, où scans, compression et agrégats rapides sont des objectifs primaires plutôt que des accessoires.
Vertica illustre clairement comment les idées de Stonebraker sur les bases analytiques se sont transformées en produit exploitable. Il a associé le stockage en colonnes à une conception distribuée, ciblant un problème précis : répondre rapidement à de grandes requêtes SQL, même quand les données dépassent un serveur unique.
MPP signifie massively parallel processing. L’idée simple : de nombreuses machines travaillent simultanément sur une même requête SQL.
Plutôt que d’avoir un serveur qui lit toutes les données et effectue tous les groupements et tris, les données sont réparties entre les nœuds. Chaque nœud traite sa part en parallèle, puis le système combine les résultats partiels en une réponse finale.
C’est ainsi qu’une requête qui prendrait des minutes sur une seule machine peut tomber à des secondes sur un cluster—à condition que les données soient bien distribuées et que la requête soit parallélisable.
Les systèmes analytiques de type Vertica excellent quand vous avez beaucoup de lignes et que vous voulez les scanner, filtrer et agréger efficacement. Cas d’usage typiques :
Les moteurs analytiques MPP ne remplacent pas les systèmes transactionnels. Ils sont optimisés pour lire beaucoup de lignes et calculer des résumés, pas pour gérer de nombreuses petites mises à jour.
Conséquences courantes :
L’idée clé est la focalisation : Vertica et systèmes similaires obtiennent leur vitesse en optimisant stockage, compression et exécution parallèle pour l’analytique—en acceptant ensuite des contraintes que les systèmes transactionnels évitent.
Une base peut « stocker et interroger » des données et pourtant rester lente pour l’analytique. La différence tient souvent moins au SQL que à la façon dont le moteur l’exécute : comment il lit les pages, déplace les données dans le CPU, utilise la mémoire et minimise le travail inutile.
Les projets analytiques de Stonebraker ont poussé l’idée que la performance des requêtes est autant un problème d’exécution que de stockage. Cette pensée a aidé les équipes à passer d’optimisations pour accès ligne par ligne à l’optimisation des longs scans, jointures et agrégations sur des millions (ou milliards) de lignes.
Beaucoup d’anciens moteurs traitent les requêtes « tuple par tuple » (ligne par ligne), générant de nombreux appels de fonctions et frais généraux. L’exécution vectorisée inverse le modèle : le moteur traite un lot (un vecteur) de valeurs dans une boucle serrée.
En clair, c’est comme pousser les courses avec un chariot plutôt que transporter un article par voyage. Le batching réduit les frais et permet aux CPU modernes d’exceller : boucles prévisibles, moins de branches, meilleur usage du cache.
Les moteurs analytiques rapides s’obsèdent sur l’efficacité CPU et cache. Les innovations d’exécution se concentrent souvent sur :
Ces idées comptent parce que les requêtes analytiques sont souvent limitées par la bande passante mémoire et les défauts de cache, pas par la vitesse brute du disque.
Les entrepôts modernes et moteurs SQL—warehouses cloud, systèmes MPP et outils analytiques en processus—utilisent fréquemment l’exécution vectorisée, des opérateurs conscients de la compression et des pipelines favorables au cache comme pratique standard.
Même quand les fournisseurs parlent d’« autoscaling » ou de « séparation stockage/compute », la vitesse perçue dépend encore beaucoup de ces choix d’exécution. Si vous évaluez une plateforme, demandez non seulement ce qu’elle stocke, mais comment elle exécute joins et agrégations en pratique—et si son modèle d’exécution est pensé pour l’analytique plutôt que pour le transactionnel.
Les données en streaming sont simplement des événements qui arrivent continuellement—pensez à un flux « quelque chose vient d’arriver » : un paiement, une lecture capteur, un clic, un scan de colis, une ligne de log : chaque élément arrive en temps réel et continue d’affluer.
Les bases traditionnelles et pipelines batch sont excellents quand on peut attendre : charger les données d’hier, exécuter des rapports, publier des tableaux de bord. Mais les besoins temps réel n’attendent pas le job horaire suivant.
Si vous ne traitez qu’en batch, vous finirez souvent avec :
Les systèmes de streaming sont conçus autour de l’idée que les calculs tournent en continu à mesure que les événements arrivent.
Une requête continue est comme une requête SQL qui ne « se termine » jamais. Au lieu de renvoyer un résultat une fois, elle met à jour le résultat au fur et à mesure que de nouveaux événements arrivent.
Parce que les flux sont non bornés, les systèmes de streaming utilisent des fenêtres pour rendre les calculs gérables. Une fenêtre est une tranche de temps ou d’événements, par exemple « les 5 dernières minutes », « chaque minute » ou « les 1 000 derniers événements ». Cela permet de calculer des comptes roulants, moyennes ou top-N sans retraiter tout l’historique.
Le streaming temps réel paie surtout quand le timing compte :
Stonebraker a soutenu pendant des décennies que les bases ne devraient pas toutes être conçues comme des machines polyvalentes « tout faire ». La raison est simple : différentes charges récompensent des choix d’architecture différents. Si vous optimisez pour un travail (par ex. petites mises à jour transactionnelles), vous dégradez souvent un autre (par ex. scanner des milliards de lignes pour un rapport).
La plupart des stacks modernes utilisent plus d’un système car l’entreprise demande plus d’un type de réponse :
C’est la réalité du « one size doesn’t fit all » : choisissez l’outil qui correspond à la forme du travail.
Utilisez ce filtre rapide quand vous choisissez (ou justifiez) un système :
Plusieurs moteurs peuvent être sains, mais seulement si chacun a une charge bien définie. Un nouvel outil doit mériter sa place en réduisant coût, latence ou risque—pas en ajoutant de la nouveauté.
Privilégiez moins de systèmes avec une forte responsabilité opérationnelle, et retirez les composants qui n’ont pas d’objectif mesurable précis.
Les fils conducteurs de la recherche de Stonebraker—fondations relationnelles, extensibilité, stockage en colonnes, exécution MPP et « le bon outil pour le job »—se voient dans les formes par défaut des plateformes de données actuelles.
L’entrepôt reflète des décennies de travail sur l’optimisation SQL, le stockage en colonnes et l’exécution parallèle. Quand vous voyez des tableaux rapides sur de grandes tables, vous voyez souvent des formats orientés colonnes plus un traitement vectorisé et une mise à l’échelle MPP.
Le lakehouse emprunte aux idées d’entrepôt (schémas, statistiques, cache, optimisation basée sur le coût) mais les place sur des formats de fichiers ouverts et du stockage objet. Le déplacement « le stockage est bon marché, le compute est élastique » est nouveau ; la réflexion sur la requête et les transactions en dessous ne l’est pas.
Les systèmes analytiques MPP (clusters shared-nothing) sont des descendants directs des recherches prouvant qu’on peut scaler SQL en partitionnant les données, en déplaçant le calcul vers les données et en gérant finement les mouvements lors des jointures et agrégations.
SQL est devenu l’interface commune aux entrepôts, moteurs MPP et même aux couches de requêtes sur les lakes. Les équipes l’utilisent comme :
Même quand l’exécution se produit dans différents moteurs (batch, interactif, streaming), SQL reste souvent le langage côté utilisateur.
Le stockage flexible n’élimine pas le besoin de structure. Schémas clairs, sens documenté et évolution contrôlée réduisent les ruptures en aval.
Une bonne gouvernance, ce n’est pas de la bureaucratie mais rendre les données fiables : définitions cohérentes, propriété, contrôles qualité et contrôles d’accès.
Quand vous évaluez des plateformes, demandez-vous :
Si un fournisseur ne peut pas mapper son produit à ces bases en langage clair, l’« innovation » est peut-être surtout du packaging.
La ligne directrice de Stonebraker est simple : les bases fonctionnent mieux quand elles sont conçues pour un travail précis—et quand elles peuvent évoluer quand ce travail change.
Avant de comparer les fonctionnalités, écrivez ce que vous devez réellement faire :
Règle utile : si vous ne pouvez pas décrire votre charge en quelques phrases (schémas de requête, taille des données, besoins de latence, concurrence), vous risquez d’acheter sur des buzzwords.
Les équipes sous-estiment la fréquence des changements : nouveaux types de données, nouvelles métriques, nouvelles règles de conformité, nouveaux consommateurs.
Favorisez des plateformes et des modèles de données qui rendent le changement routinier plutôt que risqué :
Des réponses rapides n’ont de valeur que si elles sont justes. En évaluant des options, regardez comment le système gère :
Réalisez une petite « preuve avec vos données », pas seulement une démo :
Beaucoup de conseils s’arrêtent à « choisissez le bon moteur », mais il faut aussi livrer des apps et outils internes autour de ce moteur : panneaux d’admin, dashboards, services d’ingestion et workflows back-office.
Si vous voulez prototyper rapidement sans réinventer tout votre pipeline, une plateforme de vibe-coding comme Koder.ai peut vous aider à monter des applis web (React), des services backend (Go + PostgreSQL) et même des clients mobiles (Flutter) depuis un workflow piloté par chat. C’est souvent utile pour itérer sur la conception du schéma, construire un petit « data product » interne, ou valider le comportement réel d’une charge avant de s’engager sur une infrastructure longue durée.
Pour creuser, renseignez-vous sur stockage en colonnes, MVCC, exécution MPP et traitement de flux. D’autres explications se trouvent dans /blog.
Il est rare qu’un travail de recherche devienne directement l’ADN des produits. Les idées éprouvées dans Ingres (SQL + optimisation de requêtes), Postgres (extensibilité + réflexion MVCC) et Vertica (colonnes + analytique MPP) apparaissent aujourd’hui dans la façon dont on conçoit et commercialise entrepôts, bases OLTP et plateformes de streaming.
SQL a gagné parce qu’il permet de décrire ce que l’on veut obtenir, tandis que la base de données décide comment l’obtenir efficacement. Cette séparation a permis :
Un optimiseur basé sur le coût utilise des statistiques de tables pour comparer des plans d’exécution possibles et choisir celui avec le coût attendu le plus faible (I/O, CPU, mémoire). Concrètement, cela vous aide à :
MVCC (contrôle de concurrence à versions multiples) conserve plusieurs versions d’une ligne pour que les lecteurs voient un instantané cohérent pendant que des écritures sont effectuées. En pratique :
L’extensibilité signifie que la base de données peut recevoir de nouvelles capacités — types, fonctions, index — sans que vous ayez à forker ou réécrire le moteur. C’est utile quand vous devez :
Règle opérationnelle : traitez les extensions comme des dépendances — versionnez-les, testez les montées de version et limitez qui peut les installer.
Les bases en lignes (row stores) excellent quand vous lisez ou écrivez souvent des enregistrements complets (OLTP). Les stockages en colonnes sont performants quand vous parcourez beaucoup de lignes mais n’accédez qu’à quelques champs (analytique).
Heuristique simple :
MPP (massively parallel processing) répartit les données sur plusieurs nœuds pour que de nombreuses machines exécutent une même requête SQL en parallèle. C’est pertinent pour :
Attention aux compromis : distribution des données, coûts de shuffle lors des jointures et ergonomie moindre pour les mises à jour fréquentes de lignes uniques.
L’exécution vectorisée traite les données par lots (vecteurs) plutôt qu’une ligne à la fois, réduisant les frais généraux et utilisant mieux les caches CPU. On l’observe par :
Les systèmes de batch exécutent des jobs périodiques : les données « fraîches » prennent du retard. Les systèmes de streaming considèrent les événements comme un flux continu et calculent les résultats de manière incrémentale.
Cas où le streaming est utile :
Pour rester bornés, les traitements en flux utilisent des fenêtres (par ex. les 5 dernières minutes) plutôt que « tous les temps ».
Multisystèmes quand chaque outil a une frontière de charge claire et un bénéfice mesurable (coût, latence, fiabilité). Pour éviter la prolifération :
Réutilisez la check-list décrite dans l’article et les pièces associées de /blog si besoin.
