Van kloppend hart tot vinkje in een provisioning-scherm
De database was ooit het hart van elk systeem. Bij veel organisaties is hij inmiddels gedegradeerd tot een vinkje in een provisioning-scherm en dat uitgerekend op het moment dat de datalaag bepaalt of systemen goed werken en efficiënt schalen. Hoe het zover is gekomen, snap ik overigens goed. De aandacht is niet zomaar verdwenen. Dat ging heel geleidelijk, en de redenen daarvoor zijn stuk voor stuk begrijpelijk.
Hoe de database uit beeld raakte
Het begon met de automatisering van standaardtaken: patchen, back-ups, provisioning, replicatie-instellingen. Managed services als RDS, Aurora, Cloud SQL en Azure SQL waren de logische volgende stap: cloudproviders bundelden die automatisering tot een kant-en-klare dienst. Zo werd de database in de beleving van gebruikers een non-issue. Een paar clicks en je hebt een draaiende engine. Het voelt als iets dat vanzelf gaat, en dat is fijn.
Tegelijkertijd loste de klassieke DBA-rol op in DevOps en dat gebeurde in twee stappen. De infrastructuur-DBA werd grotendeels overbodig: patchen, back-ups, replicatie en high availability doet de cloudprovider nu net zo goed, en vaak goedkoper. Maar de applicatie-DBA, degene die met het ontwikkelteam meedacht over datamodel, schemaontwerp en indexstrategie, verdween mee zonder dat er iets gelijkwaardigs voor terugkwam. Diepe databasekennis werd niet langer ergens expliciet belegd. Het werd iedereens verantwoordelijkheid, en dus van niemand.
De applicatielaag trekt ondertussen alle aandacht naar zich toe. ORM’s als Prisma, Hibernate en Entity Framework abstraheren SQL weg. Developers zijn gaan denken in objecten en endpoints, niet in query plans en isolation levels. De database is de plek waar de ORM zijn spullen neerzet. De schemaless-golf versterkte dat: met schemaless ontstond het idee dat zorgvuldig datamodelleren niet meer nodig was.
Daar komt time-to-market nog bij. Even een PostgreSQL-database opspinnen is lekker snel en werkt, op kleine schaal. Het probleem is dat de kosten van dat soort keuzes niet verdwijnen. Ze worden uitgesteld, en ze komen terug, zelden als nette technische schuld. Meestal als crisis: de cloudrekening die ontspoort, de latency die niet meer weg te krijgen is, lock contention die onder load het hele platform op de knieën dwingt.
Waar databasekennis het verschil maakt
Waar hoort al die databasekennis dan te zitten? Precies op de plek waar ze vandaag het verschil maakt tussen een platform dat schaalt en eentje dat vastloopt.
Het datamodel is het meest duurzame deel van je systeem. Code refactor je in een sprint. Een datamigratie op schaal is een project met risico, downtime en een terugrolplan. Teams kiezen naar ons idee voor de verkeerde volgorde: eerst de applicatie, daarna kijken ze wel hoe de data eronder past. Wie daarentegen de access patterns en het datamodel vooraan in het ontwerp zet, bouwt een fundament dat jaren meegaat in plaats van eentje dat over achttien maanden opnieuw op de schop moet. Die volgordekeuze is niet zomaar een detail. Het is het verschil tussen doorbouwen en opnieuw beginnen.
Het leeuwendeel van de performance- en kostenproblemen ontstaat in de datalaag. Denk aan instances die veel te ruim staan ingesteld, ontbrekende indexen, N+1-queries die de ORM stilletjes vermenigvuldigt tot duizenden roundtrips, full table scans op tabellen die alleen maar groeien en connection pooling die niet klopt. Dit zijn geen zaken in de kantlijn: precies hier komt de rekening vandaan. Dat verklaart ook waarom veel FinOps-tooling tekortschiet: die kijkt naar de factuur, niet naar de query plans die de factuur veroorzaken. Wie wel in de query plans kijkt, ziet waarom de rekening oploopt. Pas als je die oorzaak kent in plaats van het symptoom, kun je er structureel iets aan doen.
Dan is er nog AI, de reden dat dit thema nu weer bovenkomt in plaats van verder weg te zakken. RAG, vector search en agentische workloads zijn maar zo goed als de datastromen eronder. Datakwaliteit, structuur, retrieval-performance, governance en lineage worden plotseling bepalend voor de vraag of een AI-initiatief iets oplevert of een dure teleurstelling wordt. AI legt een rommelige datalaag genadeloos bloot. Je kunt het mooiste model erbovenop zetten dat je wilt, maar als de fundering scheef ligt, komen er scheuren in de muren.
De paradox
De markt heeft de database tot commodity verklaard, precies op het moment dat AI hem weer tot kritische factor maakt.
Hier zit wel een nuance. Het draait niet om de vraag welke database je kiest; die is inmiddels grotendeels commodity geworden, en daar is niets mis mee. Managed services zijn prima. De aandacht is verschoven naar hoe goed je datalaag is ontworpen, gemeten en beheerd. Daar zit het verschil. Dat is uitgerekend de kennis die de afgelopen jaren uit organisaties is weggelekt: opgelost in DevOps, verdwenen door de ORM, doorgeklikt in een provisioning-scherm.
Wie die kennis nog wel in huis heeft, of weet te organiseren, bouwt efficiënte en duurzame oplossingen. Die bouwt een voorsprong. En laat dat nu net zijn waar wij bij OptimaData al jaren ons werk van maken: de datalaag terugbrengen naar waar hij hoort, als het kloppend hart onder je applicaties, je cloud en je AI.
Wat hierna komt
Deze blog is het startpunt van een serie. De komende weken pakken we de thema’s uit dit stuk een voor een bij de kop: waarom AI-projecten stranden op de datalaag, hoe je voorkomt dat je voor verveelde GPU’s betaalt, wat NIS2 betekent zodra je AI aan je database koppelt en waarom je voor enterprise AI geen nieuwe databasesilo nodig hebt.
Wil je niet wachten en gewoon weten of jouw datafundering klaar is voor wat je ermee van plan bent? Daar hebben we de AI-Data Readiness QuickScan voor. In een paar dagen weet je waar je staat, met een helder rapport en concrete vervolgstappen. Neem gerust contact op, ook als je nog geen klant bent. We denken graag even mee.