Van A(I) naar Beter
Het probleem verdwijnt, de oorzaak blijft Stel je een enthousiaste junior systeembeheerder voor, slim, snel en eindeloos behulpzaam. Je vraagt:…
Elk AI-project een eigen database
Dit is het vierde deel van mijn serie over de datafundering onder AI. Eerder schreef ik over AI-projecten die stranden in de testfase, over verveelde GPU’s en AI-starvation, en over de vraag of je AI-koppeling NIS2-compliant is. Deze keer gaat het over een vraag die bij bijna elk AI-project vroeg of laat op tafel komt: heb je er een nieuwe database voor nodig?
Het gaat meestal zo. Een team start een pilot met een RAG-toepassing, bijvoorbeeld een chatbot die antwoorden haalt uit interne documenten of klantdata. De tutorial, de leverancier of een enthousiaste developer zegt dat je daar een vector database voor nodig hebt. Binnen een week draait er een nieuw platform naast je bestaande PostgreSQL-, SQL Server- of MongoDB-omgeving.
De pilot werkt en iedereen is blij. Dan komt de stap naar productie, en daarmee de vragen die niemand in de pilot heeft gesteld. Wie maakt er back-ups? Wie patcht het platform? Wie kijkt mee als het om drie uur ’s nachts misgaat? En hoe zorg je dat de data in die nieuwe omgeving gelijk blijft met je brondata?
Ondertussen start een ander team een tweede AI-project, met een tweede vector database. Voor je het weet beheer je een verzameling losse eilanden.
Wat een extra silo je echt kost
Een nieuwe database spin je zo op. De rekening komt later, en die bestaat uit meer dan een licentie of abonnement.
Beheerlast. Elk platform vraagt eigen kennis, monitoring, back-ups en updates. Vaak is er precies één collega die het snapt. Daarmee heb je er een single point of failure bij.
Data die achterloopt. Wie data kopieert naar een aparte omgeving, moet die blijven synchroniseren. Loopt dat proces achter, dan antwoordt je AI op de stand van gisteren. Dat lijkt op hallucineren, maar het model doet niets fout: de data klopt niet.
Beveiliging en NIS2. Gevoelige bedrijfsdata staat ineens op een tweede plek, met een eigen toegangsmodel en eigen logging. Dat is een extra aanvalsoppervlak en een extra hoofdstuk in je NIS2-verantwoording, die in Nederland sinds 15 augustus 2026 is vastgelegd in de Cyberbeveiligingswet (Cbw). Bouw je je aanpak op NEN-EN-ISO/IEC 27001:2023+A1:2024, dan hoort die tweede omgeving ook in je risicoanalyse en je maatregelen.
Kosten. Dubbele opslag, extra compute, dataverkeer tussen omgevingen en uren voor beheer. Vectoren vragen bovendien veel geheugen, dus de kosten lopen bij groei sneller op dan je verwacht.
Lock-in. Een deel van de gespecialiseerde vectordiensten, zoals Pinecone, is propriëtaire SaaS. Overstappen is later lastiger dan instappen.
Je bestaande database kan meer dan je denkt
De database die je al jaren gebruikt, kan vaak prima vectoren opslaan en doorzoeken. Met de extensie pgvector wordt PostgreSQL een volwaardige basis voor RAG en semantisch zoeken. SQL Server, Azure SQL, MariaDB en MongoDB hebben inmiddels ook vectorondersteuning aan boord, al verschilt de volwassenheid per platform. Bij SQL Server 2025 is de vectorindex nog in preview, en MongoDB biedt vector search buiten Atlas pas vanaf versie 8.2.
Het voordeel gaat veel verder dan één platform minder om te beheren. Je vectoren staan naast je bedrijfsdata, met dezelfde back-up en dezelfde toegangsrechten. Werk je een klantrecord bij, dan kun je de bijbehorende embedding direct mee bijwerken. Zo voorkom je dat je AI zoekt in een losse kopie die achterloopt.
Bovendien zoek je slimmer. Semantisch zoeken combineer je in één query met gewone filters: alleen documenten van deze klant, van na 1 januari, waar deze medewerker rechten op heeft. In een losse vector database moet je die metadata en rechten eerst kopiëren, en ze daarna blijven bijhouden.
Aanzetten is iets anders dan goed laten draaien
Een kanttekening hoort erbij. Een extensie installeren is vijf minuten werk. Hem in productie goed laten presteren is vakwerk.
Vectorindexen zoals HNSW willen bij voorkeur in het geheugen passen. Een verkeerd gekozen of slecht afgestelde index maakt je AI traag, en dan wacht je hele AI-keten op de database. Daarnaast vraagt een AI-workload iets anders van je database dan je vertrouwde applicatie: meer gelijktijdige leesacties, andere querypatronen en meer druk op I/O.
Draait je database als managed dienst bij een cloudprovider of in een container op Kubernetes? Dan regelt die partij de infrastructuur. Indexen, tuning en datakwaliteit blijven jouw verantwoordelijkheid. Managed is niet hetzelfde als geoptimaliseerd.
Wanneer een aparte vector database toch logisch is
Eerlijk is eerlijk, soms is een gespecialiseerd platform de betere keuze. Bijvoorbeeld bij honderden miljoenen vectoren of meer, bij extreem strenge eisen aan responstijd, of als vector search een zelfstandige dienst is die los staat van je transactionele data.
Dan is een dedicated platform zoals Qdrant, Weaviate of Milvus prima te verdedigen. Maak het dan wel een bewuste keuze, met beheer, beveiliging en synchronisatie vanaf dag één geregeld. Een tutorial is geen architectuurbesluit.
Het platform dat je al vertrouwt klaar voor AI
Wij bouwen liever geen nieuwe eilanden. We maken het platform dat je al vertrouwt klaar voor AI, of dat nu PostgreSQL, SQL Server, MySQL, MariaDB of MongoDB is, on-prem, in de cloud of op Kubernetes.
Daarvoor hebben we de AI Data Readiness QuickScan. In een paar dagen brengen we in kaart:
- of je database de doorvoer levert om je AI-toepassingen bij te houden;
- of je vector- en indexstructuur goed is ingericht;
- of je AI geen verouderde of dubbele data te zien krijgt;
- waar je kosten bespaart door slimmer te schalen.
Je krijgt een helder rapport met concrete vervolgstappen, tegen een vaste prijs. Zo weet je of je bestaande database het werk aankan, of dat een apart platform in jouw situatie echt nodig is.
Wie deze serie heeft gevolgd, ziet één rode draad. Of het nu gaat om een pilot die strandt, GPU’s die op data staan te wachten, een AI-koppeling die je NIS2-verantwoording op de proef stelt of een extra silo die ongemerkt naast je omgeving groeit: de oorzaak ligt zelden bij het model. Ze ligt in de datalaag eronder. Net als bij die brisket zit het verschil in het vakmanschap waarmee je het apparaat dat je al hebt laat presteren.
In het volgende deel gaan we een laag dieper. Want wat als die fundering ook aangetast raakt? We kijken naar datacorruptie in AI-omgevingen en naar ransomware, en naar wat dat betekent voor de betrouwbaarheid van alles wat je AI je vertelt.
Nieuwsgierig waar jouw datafundering staat? Bel of mail ons gerust, ook als je nog geen klant bent. We denken graag met je mee.
