De database is commodity verklaard, precies nu hij weer het verschil maakt
(en hoe je dit voorkomt)
Je koopt geen Ferrari om er vervolgens mee over een zandpad te ploeteren. Toch gebeurt dat bij steeds meer bedrijven zodra ze met AI aan de slag gaan. Er gaat fors budget naar GPU-capaciteit en het nieuwste taalmodel, de POC oogt veelbelovend, en dan gaat de chatbot of het AI-agent-project live. Hij reageert traag, geeft onlogische antwoorden, soms ronduit foute. Daarna volgt de conclusie die je steeds vaker in het nieuws leest: AI levert toch niet op wat beloofd was, tijd om de investering terug te draaien.
Edco Wallet, medeoprichter en eigenaar van OptimaData, ziet het bij steeds meer klanten gebeuren. In deze blog legt hij uit waarom de oorzaak zelden bij het model ligt en bijna altijd bij de datalaag eronder.
Zodra een AI-project tegenvalt, valt al snel de conclusie dat het model niet deugt. Ik snap dat, maar het klopt bijna nooit. Het model doet zijn werk prima. Het gaat mis in de laag eronder.
Elke AI-toepassing die iets met jouw bedrijfsdata doet, leunt op een datastroom die ergens bij een database begint. RAG-toepassingen doen embeddings en retrieval op basis van de onderliggende data. Agentische workloads vuren continu queries af om context op te halen en beslissingen te onderbouwen. Staat die datalaag niet klaar voor dat soort belasting, dan gaat het mis, en dat merk je pas zodra je van testomgeving naar productie gaat. Je AI wordt pas slim als je database dat is.
In de testfase draait alles op een handjevol records en een paar testgebruikers. Niemand merkt dat een query een full table scan doet of dat een fatsoenlijke index ontbreekt. Zodra het volume omhooggaat, tikken die zaken keihard door: trage retrieval, oplopende latency en een chatbot die twijfelt of het verkeerde antwoord geeft omdat de brondata rommelig, verouderd of inconsistent is.
Wat er in productie misgaat, is bij OptimaData zelden exotisch. Vier patronen komen steeds terug:
Dit zijn geen kleine technische details. Dit is de fundering. Een AI-model op een scheve fundering zetten levert scheuren op, hoe krachtig dat model ook is.
Dat dit steeds opnieuw gebeurt, valt wel te verklaren. AI-projecten starten vaak vanuit de datascience- of platformhoek, met de nadruk op modelkeuze, prompting en GPU-capaciteit. De database zit ondertussen ergens onderin de stack, verstopt achter een pipeline, in een container, soms als ‘managed’ clouddienst waar niemand meer naar omkijkt. Precies zoals Gerard eerder al schreef: de database is tot commodity verklaard, op het moment dat AI hem weer beslissend maakt.
Het gevolg: budget verdwijnt in tokens en GPU-uren, terwijl de echte bottleneck een niveau lager ligt. Je kunt er het duurste model bovenop zetten, maar als de data-infrastructuur eronder niet meeschaalt of vervuilde data aanlevert, koop je geen goed resultaat.
Een groter model of meer GPU’s lossen dit niet op. Wat wel helpt: je datafundering serieus nemen, het liefst voordat je live gaat en niet erna.
Concreet betekent dat:
Wij zien de database niet als een vinkje in een provisioning-scherm, maar als het kloppend hart onder je AI-platform. Dat vraagt aandacht die verder gaat dan een druk op de knop.
Wil je weten of jouw datafundering klaar is voor de AI-workloads die je erop wilt loslaten, voordat je daar in productie achter komt? Daarvoor hebben we de AI-Data Readiness QuickScan. In een paar dagen krijg je een helder beeld van waar de risico’s zitten, met concrete vervolgstappen. Neem gerust contact op, ook als je nog geen klant bent. We denken graag mee.