07 jun 2025·8 min
Michael Stonebraker en moderne databases: wat hij veranderde
Ontdek Michael Stonebrakers kernideeën achter Ingres, Postgres en Vertica — en hoe ze SQL‑databases, analytics‑engines en hedendaagse datastacks hebben gevormd.
Ontdek Michael Stonebrakers kernideeën achter Ingres, Postgres en Vertica — en hoe ze SQL‑databases, analytics‑engines en hedendaagse datastacks hebben gevormd.
Michael Stonebraker is een computerwetenschapper wiens projecten niet alleen de database‑onderzoeksgemeenschap beïnvloedden — ze hebben direct de producten en ontwerpprincipes gevormd waarop veel teams dagelijks vertrouwen. Als je een relationele database, een analytics-warehouse of een streamingsysteem hebt gebruikt, heb je geprofiteerd van ideeën die hij hielp bewijzen, bouwen of populariseren.
Dit is geen biografie of een academische rondleiding door databasetheorie. In plaats daarvan koppelt het Stonebrakers belangrijkste systemen (zoals Ingres, Postgres en Vertica) aan keuzes die je in moderne datastacks ziet:
Een moderne database is elk systeem dat betrouwbaar kan:
Verschillende databases optimaliseren deze doelen op verschillende manieren — vooral als je transactionele apps, BI‑dashboards en realtime pipelines vergelijkt.
We richten ons op praktische impact: de ideeën die vandaag in de “warehouse + lake + stream + microservices”-wereld opduiken, en hoe ze beïnvloeden wat je koopt, bouwt en beheert. Verwacht duidelijke uitleg, afwegingen en praktische implicaties — geen diepe wiskundige bewijzen of implementatiedetails.
Stonebrakers carrière is het makkelijkst te begrijpen als een opeenvolging van systemen gebouwd voor specifieke taken — waarna de beste ideeën naar mainstream databaseproducten migreerden.
Ingres begon als een academisch project dat aantoonde dat relationele databases snel en praktisch konden zijn, niet alleen theorie. Het droeg bij aan de populariteit van SQL‑achtige query's en het denken over cost‑based optimalisatie dat later normaal werd in commerciële engines.
Postgres (het onderzoekssysteem dat tot PostgreSQL leidde) onderzocht een andere inzet: databases moeten geen vastomlijnde functie zijn. Je moet nieuwe datatypen, nieuwe indexmethoden en rijkere gedragingen kunnen toevoegen zonder de hele engine te herschrijven.
Veel “moderne” features gaan terug naar deze periode — uitbreidbare types, user‑defined functions en een database die zich aanpast als workloads veranderen.
Naarmate analytics groeiden, worstelden rij‑georiënteerde systemen met grote scans en aggregaties. Stonebraker promotede kolomgebaseerde opslag en bijbehorende uitvoeringstechnieken gericht op het alleen lezen van de benodigde kolommen en goede compressie — ideeën die nu standaard zijn in analytics‑databases en cloudwarehouses.
Vertica nam kolomstore‑onderzoek en zette het om in een commercieel levensvatende massively parallel processing (MPP) SQL‑engine voor grote analytische queries. Dit patroon herhaalt zich: een onderzoeksprototype valideert een concept; een product maakt het robuust voor betrouwbaarheid, tooling en echte klantvereisten.
Later werk breidde uit naar streamverwerking en workload‑specifieke engines — met het argument dat één algemene database zelden overal de beste keuze is.
Een prototype is gebouwd om een hypothese snel te testen; een product moet operationele aspecten prioriteren: upgrades, monitoring, beveiliging, voorspelbare prestaties en support. Stonebrakers invloed is zichtbaar omdat veel prototype‑ideeën in commerciële databases zijn gegroeid tot standaardmogelijkheden in plaats van nicheopties.
Ingres (afkorting van INteractive Graphics REtrieval System) was Stonebrakers vroege bewijs dat het relationele model meer kon zijn dan elegante theorie. Destijds waren veel systemen gebouwd rond aangepaste toegangsmethoden en applicatie‑specifieke datapaden.
Ingres stelde een eenvoudig, zakelijk vriendelijk probleem centraal:
Hoe laat je mensen flexibele vragen stellen over data zonder bij elke wijziging de software te herschrijven?
Relationele databases beloofden dat je kon beschrijven wat je wilt (bijv. "klanten in Californië met openstaande facturen") in plaats van hoe je het stap voor stap ophaalt. Maar om die belofte waar te maken was een systeem nodig dat kon:
Ingres was een belangrijke stap richting die praktische versie van relationeel rekenwerk — eentje die op toenmalige hardware responsief kon aanvoelen.
Ingres droeg bij aan het idee dat een database het moeilijke werk van het plannen van queries moet doen. In plaats van ontwikkelaars elke toegangspad handmatig te tunen, koos het systeem strategieën zoals welke tabel eerst te lezen, welke indexen te gebruiken en hoe tabellen te joinen.
Dat versnelde de verspreiding van SQL‑denken: als je declaratieve queries kunt schrijven, iterateer je sneller en kunnen meer mensen vragen stellen — analisten, productteams, zelfs finance — zonder te wachten op maatwerkrapporten.
Het grote praktische inzicht is cost‑based optimalisatie: kies het query‑plan met de laagste verwachte “kost” (meestal een mix van I/O, CPU en geheugen), op basis van statistieken over de data.
Dat betekent vaak:
Ingres heeft niet elk stukje moderne optimalisatie uitgevonden, maar hielp het patroon te vestigen: SQL + een optimizer is wat relationele systemen schaalbaar maakt van “leuk idee” tot dagelijks hulpmiddel.
Vroege relationele databases gingen uit van een vaste set datatypen (getallen, tekst, datums) en een vaste set bewerkingen (filter, join, aggregate). Dat werkte goed — totdat teams nieuwe soorten informatie gingen opslaan (geografie, logs, time series, domein‑specifieke identifiers) of gespecialiseerde prestatiefeatures nodig hadden.
Bij een rigide ontwerp leidt elk nieuw vereiste vaak tot slechte keuzes: data in tekstblobs proppen, een apart systeem eraan vastknopen, of wachten tot een leverancier ondersteuning toevoegt.
Postgres zette een ander idee centraal: een database moet uitbreidbaar zijn — je moet nieuwe mogelijkheden op een gecontroleerde manier kunnen toevoegen zonder de veiligheid en correctheid van SQL op te offeren.
In gewone taal is extensibiliteit alsof je gecertificeerde hulpstukken aan een elektrisch gereedschap toevoegt in plaats van de motor zelf te herbedraden. Je leert de database nieuwe trucjes, terwijl transacties, permissies en query‑optimalisatie als een coherent geheel blijven werken.
Die denkwijze zie je duidelijk in het hedendaagse PostgreSQL‑ecosysteem (en veel Postgres‑geïnspireerde systemen). In plaats van te wachten op een kernfeature, kunnen teams goedgekeurde extensies gebruiken die naadloos integreren met SQL en operationele tooling.
Algemene voorbeelden zijn:
Het belangrijkste is dat Postgres het veranderen van wat de database kan doen als ontwerpdoel behandelde — niet als afterthought — en dat idee beïnvloedt nog steeds hoe moderne dataplatten groeien.
Databases gaan niet alleen over data opslaan — ze zorgen ervoor dat die data klopt, zelfs als er veel tegelijk gebeurt. Dat is waar transacties en concurrency control voor zijn, en het is een belangrijke reden dat SQL‑systemen vertrouwd worden voor echt zakelijk werk.
Een transactie is een groep wijzigingen die ofwel volledig slagen of volledig falen.
Als je geld tussen rekeningen overmaakt, een bestelling plaatst of voorraad bijwerkt, kun je je geen “half‑afgewerkte” resultaten veroorloven. Een transactie zorgt dat je niet met een bestelling eindigt die een klant heeft belast zonder de voorraad te reserveren — of met voorraadvermindering zonder bijbehorende bestelling.
In praktische termen geven transacties je:
Gelijktijdigheid betekent dat veel mensen (en apps) tegelijk data lezen en wijzigen: checkout‑acties, supportmedewerkers die accounts bewerken, achtergrondjobs die statussen updaten, analisten die rapporten draaien.
Zonder zorgvuldige regels ontstaan problemen zoals:
Een invloedrijke aanpak is MVCC (Multi‑Version Concurrency Control). Conceptueel houdt MVCC korte tijd meerdere versies van een rij bij, zodat lezers een stabiele snapshot behouden terwijl schrijvers updates doen.
Het grote voordeel is dat reads schrijfbewerkingen minder vaak blokkeren, en schrijvers niet voortdurend stilstaan achter langlopende query's. Je behoudt correctheid met minder wachten.
De databases van vandaag dienen vaak gemixte workloads: veel app‑writes naast frequente reads voor dashboards, klantviews en operationele analytics. Moderne SQL‑systemen vertrouwen op technieken als MVCC, slimmer locken en isolatieniveaus om snelheid en correctheid in balans te houden — zodat je activiteit kunt opschalen zonder vertrouwen in de data te verliezen.
Rijgeoriënteerde databases waren gebouwd voor transactionele verwerking: veel kleine reads en writes, typisch één klant, één bestelling of één account tegelijk. Dat ontwerp is prima als je snel een heel record moet ophalen of bijwerken.
Denk aan een spreadsheet. Een rijstore is als elke rij in een eigen map bewaren: als je “alles over Order #123” nodig hebt, pak je die ene map. Een kolomstore is als sorteren per kolom: één lade voor "order_total", een andere voor "order_date", weer een andere voor "customer_region".
Voor analytics heb je zelden de hele map nodig — meestal vraag je iets als "Wat was de totale omzet per regio afgelopen kwartaal?" Die query raakt misschien slechts een paar velden over miljoenen records.
Analytics‑queries:
Met kolomopslag kan de engine alleen de in de query vermelde kolommen lezen, de rest overslaan. Minder data van schijf lezen (en minder door geheugen verplaatsen) is vaak de grootste prestatiewinst.
Kolommen hebben vaak repetitieve waarden (regio's, statussen, categorieën). Dat maakt ze goed comprimeerbaar — en compressie kan analytics versnellen omdat het systeem minder bytes leest en soms op gecomprimeerde data kan opereren.
Kolomstores markeerden de verschuiving van OLTP‑first databases naar analytics‑first engines, waar scannen, compressie en snelle aggregaties primaire ontwerpdoelen werden in plaats van bijzaak.
Vertica is een duidelijk praktisch voorbeeld van hoe Stonebrakers ideeën over analytics‑databases in een product werden gegoten dat teams in productie konden draaien. Het combineerde kolomstore‑lessen met een gedistribueerd ontwerp gericht op één probleem: grote analytische SQL‑queries snel beantwoorden, zelfs als data te groot wordt voor één server.
MPP staat voor massively parallel processing. Het eenvoudigst is te denken: veel machines werken tegelijkertijd aan één SQL‑query.
In plaats van één database‑server die alle data leest en alles sorteert en groepeert, wordt de data over knooppunten verdeeld. Elk knooppunt verwerkt zijn deel parallel, en het systeem combineert de tussentijdse resultaten tot een eindantwoord.
Zo kan een query die minuten zou duren op één machine teruggebracht worden tot seconden op een cluster — mits de data goed verdeeld is en de query paralleliseerbaar is.
Vertica‑achtige MPP‑analyticsystemen blinken uit wanneer je veel rijen hebt en die efficiënt wilt scannen, filteren en aggregeren. Typische use cases:
MPP‑analyticsengines zijn geen drop‑in vervanging voor OLTP. Ze zijn geoptimaliseerd voor veel rijen lezen en samenvattingen berekenen, niet voor veel kleine updates.
Daardoor ontstaan gebruikelijke trade‑offs:
De kern is focus: Vertica en soortgelijke systemen verdienen hun snelheid door opslag, compressie en parallelle uitvoering voor analytics te tunen — en accepteren vervolgens beperkingen die transactionele systemen vermijden.
Een database kan data opslaan en query'en en toch traag aanvoelen voor analytics. Het verschil zit vaak niet in de SQL die je schrijft, maar in hoe de engine die uitvoert: hoe hij pagina's leest, data door de CPU verplaatst, geheugen gebruikt en onnodig werk minimaliseert.
Stonebrakers analytics‑projecten stelden dat query‑performance net zo goed een uitvoeringsprobleem is als een opslagprobleem. Dat heeft teams doen verschuiven van optimalisatie voor single‑row lookups naar optimalisatie voor lange scans, joins en aggregaties over miljoenen (of miljarden) rijen.
Veel oudere engines verwerken queries "tuple‑per‑tuple" (rij‑voor‑rij), wat veel functieaanroepen en overhead brengt. Vectorized execution keert dat om: de engine verwerkt een batch (een vector) van waarden in een strakke lus.
In gewone termen is het alsof je boodschappen met een kar retouneert in plaats van één item per keer te dragen. Batching vermindert overhead en laat moderne CPU's doen waar ze goed in zijn: voorspelbare lussen, minder branches en beter cachegebruik.
Snel werkende analytics‑engines letten obsessief op CPU‑ en cache‑efficiëntie. Uitvoeringsinnovaties richten zich vaak op:
Deze ideeën tellen omdat analytics‑queries vaak beperkt worden door geheugenbandbreedte en cache‑misses, niet door ruwe schijfsnelheid.
Moderne datawarehouses en SQL‑engines — cloudwarehouses, MPP‑systemen en snelle in‑process analytics‑tools — gebruiken vaak vectorized execution, compressie‑bewuste operators en cache‑vriendelijke pijplijnen als standaardpraktijk.
Zelfs wanneer vendors functies als “autoscaling” of “separation of storage and compute” adverteren, hangt de dagelijkse snelheid die je voelt nog steeds sterk af van deze uitvoeringkeuzes.
Als je platforms evalueert, vraag dan niet alleen wat ze opslaan, maar hoe ze joins en aggregaties uitvoeren onder de motorkap — en of hun uitvoeringsmodel voor analytics is gebouwd in plaats van voor transactionele workloads.
Streamingdata is simpelweg data die continu binnenkomt als een reeks events — denk aan een creditcard‑swipe, een sensormeting, een klik op een productpagina, een pakketscan, een logregel: elk item verschijnt in real time en blijft binnenkomen.
Traditionele databases en batchpijplijnen zijn prima als je kunt wachten: laad de data van gisteren, voer rapporten uit, publiceer dashboards. Maar realtime behoeften wachten niet op de volgende uurlijkse job.
Als je alleen in batches verwerkt, eindig je vaak met:
Streaming‑systemen zijn ontworpen rond het idee dat berekeningen continu kunnen draaien terwijl events binnenkomen.
Een continue query is als een SQL‑query die nooit "klaar" is. In plaats van eenmalig resultaat bij terugkeer, werkt het resultaat bij naarmate nieuwe events binnenkomen.
Omdat streams onbegrensd zijn (ze houden niet op), gebruiken streaming‑systemen windows om berekeningen beheersbaar te maken. Een window is een tijds- of eventslice, zoals "de laatste 5 minuten", "elke minuut" of "de laatste 1.000 events". Daarmee kun je rollende counts, gemiddelden of top‑N lijsten berekenen zonder alles opnieuw te verwerken.
Realtime streaming is het meest waardevol wanneer timing ertoe doet:
Stonebraker heeft decennialang betoogd dat databases niet allemaal als general‑purpose "doe‑alles" machines gebouwd moeten worden. De reden is simpel: verschillende workloads belonen verschillende ontwerpkeuzes. Als je hard optimaliseert voor één taak (bijv. kleine transactionele updates), maak je vaak een andere taak trager (zoals het scannen van miljarden rijen voor een rapport).
De meeste moderne stacks gebruiken meer dan één datasysteem omdat het bedrijf om meer dan één soort antwoord vraagt:
Dat is in de praktijk: één maat past niet iedereen — je kiest engines die bij de vorm van het werk passen.
Gebruik dit snelle filter bij het kiezen (of rechtvaardigen) van een systeem:
Meerdere engines kunnen gezond zijn, maar alleen als elke engine een duidelijke workload heeft. Een nieuw hulpmiddel moet zijn plaats verdienen door kosten, latency of risico te verlagen — niet door nieuwigheid.
Geef de voorkeur aan minder systemen met sterk operationeel eigenaarschap en zet onderdelen uit die geen scherp, meetbaar doel hebben.
Stonebrakers onderzoekslijnen — relationele fundamenten, extensibiliteit, kolomstores, MPP‑uitvoering en "het juiste gereedschap voor de taak" — zijn zichtbaar in de standaardvormen van moderne dataplatten.
Het warehouse weerspiegelt decennia werk aan SQL‑optimalisatie, kolomgebaseerde opslag en parallelle uitvoering. Wanneer je snelle dashboards op enorme tabellen ziet, zie je vaak kolomgeoriënteerde formaten plus vectorized processing en MPP‑achtige schaal.
De lakehouse leent warehouse‑ideeën (schema's, statistieken, caching, cost‑based optimalisatie) maar plaatst ze op open bestandsformaten en objectopslag. De verschuiving naar "opslag is goedkoop, compute is elastisch" is nieuw; het query‑ en transactiedenken eronder is dat niet.
MPP‑analyticsystemen (shared‑nothing clusters) zijn directe nakomelingen van onderzoek dat aantoonde dat je SQL kunt schalen door data te partitioneren, berekening naar data te verplaatsen en databeweging bij joins en aggregaties zorgvuldig te beheren.
SQL is de gemeenschappelijke interface geworden over warehouses, MPP‑engines en zelfs "lake" querylagen. Teams gebruiken het als:
Zelfs wanneer uitvoering in verschillende engines plaatsvindt (batch, interactief, streaming), blijft SQL vaak de gebruikersgerichte taal.
Flexibele opslag maakt structuur niet overbodig. Duidelijke schema's, gedocumenteerde betekenis en gecontroleerde evolutie verminderen downstream‑breuk.
Goede governance gaat minder over bureaucratie en meer over data betrouwbaar maken: consistente definities, eigenaarschap, kwaliteitschecks en toegangscontrole.
Bij het evalueren van platforms, vraag:
Als een vendor hun product niet in eenvoudige taal aan deze basics kan koppelen, is de "innovatie" mogelijk vooral verpakking.
Stonebrakers rode draad is eenvoudig: databases werken het best als ze voor een specifieke taak zijn ontworpen — en als ze kunnen evolueren als die taak verandert.
Schrijf eerst op wat je werkelijk moet doen:
Een nuttige regel: als je je workload niet in een paar zinnen kunt beschrijven (querypatronen, datagrootte, latencybehoeften, concurrentie), ga je op buzzwords kiezen.
Teams onderschatten hoe vaak eisen verschuiven: nieuwe datatypen, nieuwe metrics, nieuwe compliance‑regels, nieuwe consumenten.
Geef de voorkeur aan platforms en datamodellen die verandering routineus maken in plaats van risicovol:
Snelle antwoorden zijn alleen waardevol als ze de juiste antwoorden zijn. Bij het evalueren van opties, vraag hoe het systeem omgaat met:
Doe een kleine "proof met je data", niet alleen een demo:
Veel databaseadvies stopt bij "kies de juiste engine", maar teams moeten ook apps en interne tools rond die engine afleveren: adminpanelen, metrics‑dashboards, ingestie‑services en backoffice‑workflows.
Als je snel wilt prototype'en zonder je hele pipeline opnieuw uit te vinden, kan een vibe‑coding platform zoals Koder.ai je helpen webapps (React), backend‑services (Go + PostgreSQL) en zelfs mobiele clients (Flutter) op te zetten vanuit een chatgestuurde workflow. Dat is vaak nuttig bij het itereren op schema‑ontwerp, het bouwen van een klein intern "data product" of het valideren van hoe een workload echt gedraagt voordat je op lange termijn infrastructuur commit.
Als je dieper wilt duiken, zoek naar uitleg over kolomgebaseerde opslag, MVCC, MPP‑uitvoering en streamverwerking. Meer uitleg staat in /blog.
Hij is een zeldzaam voorbeeld waarbij onderzoeksprojecten de kern van echte producten werden. Ideeën bewezen in Ingres (SQL + query-optimalisatie), Postgres (extensibiliteit + MVCC-denken) en Vertica (kolomgebaseerde opslag + MPP-analytics) komen vandaag terug in hoe warehouses, OLTP-databases en streamingplatforms zijn gebouwd en gepositioneerd.
SQL won omdat het je laat beschrijven wat je wilt, terwijl de database uitzoekt hoe dat efficiënt te halen is. Die scheiding maakte het mogelijk om:
Een cost-based optimizer gebruikt statistieken over tabellen om mogelijke queryplannen te vergelijken en die met de laagste verwachte kosten te kiezen (I/O, CPU, geheugen). In de praktijk helpt het je om:
MVCC (Multi-Version Concurrency Control) bewaart meerdere versies van rijen zodat lezers een consistente snapshot kunnen zien terwijl schrijvers updaten. In het dagelijks gebruik betekent dat:
Extensibiliteit betekent dat de database veilig nieuwe mogelijkheden kan krijgen—types, functies, indexen—zonder dat je de engine moet forken of herschrijven. Het is handig als je wilt:
De operationele vuistregel: behandel extensies als dependencies—versioneer ze, test upgrades en beperk wie ze kan installeren.
Rijgeoriënteerde opslag is geweldig wanneer je vaak hele records leest of schrijft (OLTP). Kolomgebaseerde opslag blinkt uit wanneer je veel rijen scant maar slechts enkele velden nodig hebt (analytics).
Een eenvoudige vuistregel:
MPP (massively parallel processing) verdeelt data over knooppunten zodat veel machines samen aan één SQL-query werken. Het is sterk geschikt voor:
Let op trade-offs zoals datadistributiekeuzes, shuffle-kosten tijdens joins en minder goede ergonomie voor hoge-frequentie single-row updates.
Vectorized execution verwerkt data in batches (vectoren) in plaats van rij-voor-rij, waardoor overhead vermindert en CPU-caches beter benut worden. Je merkt het meestal als:
Batchsystemen voeren periodieke jobs uit, waardoor data vaak verouderd is. Streaming-systemen behandelen events als een continue input en rekenen incrementeel bij.
Situaties waarin streaming direct lonend is:
Streaming gebruikt windows (bijv. laatste 5 minuten) om berekeningen begrensd te houden in plaats van “alles ooit.”
Gebruik meerdere systemen wanneer elk een duidelijke workload-grens en meetbaar voordeel heeft (kosten, latency, betrouwbaarheid). Om toolsprawl te vermijden:
Als je een selectieframework nodig hebt, hergebruik de checklist-gedachte uit het artikel en gerelateerde stukken in /blog.