Ik verhuisde een dataplatform van Databricks naar één VM en bespaarde 95% per maand

Dit is een technische terugblik. Om bedrijfsinformatie te beschermen, laat ik absolute kosten, datavolumes, omgevingsidentiteiten en exacte resourceconfiguraties weg.

De afgelopen maanden heb ik de dagelijkse runtime van een dataplatform verhuisd van Databricks en ADF naar één VM. De nieuwe runtime bestaat uit Airflow, DuckDB/Polars en DuckLake. De databestanden blijven in object storage.

Na de migratie daalden de maandelijkse operationele kosten van dit platform met ongeveer 95%.

Dat percentage valt op, maar de aanleiding ontstond tijdens het ontwikkelen. Naarmate ik AI-agents vaker inzette, kon ik sneller code schrijven en ideeën onderzoeken. Verkennend werk kreeg ook een groter aandeel in mijn dagelijkse ontwikkeling. De feedbackcyclus en het prijsmodel van het platform sloten steeds minder goed aan op dit nieuwe tempo.

Het probleem: AI-agents versnelden experimenten en vergrootten het kostenrisico

Data-engineering vraagt om herhaling. Een engineer neemt een sample, past een transformatie aan, draait een job opnieuw, controleert randgevallen en wijzigt de code nogmaals. Met een AI-agent kan die cyclus veel sneller verlopen en meerdere rondes achter elkaar doorgaan.

Dat leverde een praktisch risico op. Met prompts en code reviews kon ik niet garanderen dat een agent het scanvolume, de benodigde rekenkracht en het aantal retries iedere keer goed zou inschatten. Een gewone dataverkenning kon dure Databricks-compute starten. Automatische retries na een fout konden de rekening verder laten oplopen. De ontwikkeling ging sneller en de maandelijkse kosten werden minder voorspelbaar.

Tegelijkertijd onderzocht ik de werkelijke looptijden en het resourcegebruik van de jobs. De dagelijkse ETL-belasting was vrij stabiel en een passend ingerichte machine kon het werk binnen het vereiste tijdsvenster afronden. Het bestaande platform bood krachtige elasticiteit en ondersteuning voor meerdere teams, maar het platform had die mogelijkheden op de huidige schaal maar weinig nodig.

De runtime zag er ongeveer zo uit:

ADF → Databricks / Unity Catalog → object storage

Elk onderdeel had een duidelijke functie. Toch moest een alledaagse codewijziging langs de orchestrator, het computeplatform, rechten, container-images, repositories en deploymentpipelines voordat een ontwikkelaar wist of de code in de echte omgeving werkte.

Het probleem: CI/CD maakte iedere validatiecyclus te lang

Een kleine wijziging volgde vaak dit pad:

code wijzigen → commit → wachten op CI/CD → op afstand deployen → job draaien → logs bekijken

Zelfs wanneer lokale tests slaagden, kon de cloudrun nog stuklopen op een ontbrekend package, een service-identiteit, een imageversie of een permissie. Daarna volgde een correctie en begon dezelfde route opnieuw.

Toen codegeneratie sneller werd, nam wachten een groter deel van de cyclus in. Een AI-agent kon binnen enkele minuten een wijziging maken, terwijl de engineer en de agent nog steeds op een remote CI/CD-run moesten wachten voor het volgende bruikbare signaal. Het aantal echte validaties dat ik in een uur kon uitvoeren werd een belangrijke begrenzing voor de ontwikkelsnelheid.

Extra CI-capaciteit nam die vertraging niet weg. De CI/CD-pipeline droeg nog steeds te veel validatiewerk uit de verkennende fase en ieder experiment legde de volledige remote route af.

De aanpak: de dagelijkse runtime op één VM samenbrengen

Eerst bevestigde ik met historische jobgegevens dat één machine de dagelijkse workload van het platform kon dragen. Daarna bracht ik de hoofdroute terug tot:

Airflow + DuckDB/Polars (VM)
              ↓
DuckLake-catalogus: relationele metadatadatabase + Parquet in object storage

Airflow verzorgt de orchestratie en DuckDB/Polars voert transformaties uit. DuckLake bewaart catalogus- en snapshotmetadata in een relationele database, terwijl Parquet-bestanden in object storage blijven. De migratie veranderde de plek waar compute, planning en ontwikkelfeedback plaatsvinden. De data werd niet aan de lokale schijf van de VM gekoppeld.

Docker Compose beschrijft de runtime. De lokale ontwikkelomgeving en de VM gebruiken dezelfde containerdefinities, dependencies en servicerelaties. Engineers en AI-agents kunnen de Compose-configuratie, Dockerfiles, requirements, DAG’s en tests lezen om te begrijpen waar de code uiteindelijk draait.

Daardoor werden veel foutroutes korter. Ontbrekende dependencies zijn lokaal te reproduceren, wijzigingen aan images kunnen direct worden getest en joblogs zijn beschikbaar in een runtime die het team zelf kan inspecteren. Validatie met echte data gebeurt nog steeds in een gecontroleerde omgeving. Wijzigingen aan host, netwerk en RBAC blijven via infrastructuurcode beheerd.

De aanpak: experimenteren en formele oplevering krijgen elk hun eigen tempo

Ik behield pull requests, CI, reviews en geautoriseerde deployments voor een controleerbaar opleverproces. Daarnaast voegde ik een gecontroleerde route voor snelle validatie toe:

valideren met lokale Compose
        ↓
echte input draaien in een gedeelde validatieomgeving
        ↓
aanpassen en herhalen
        ↓
PR / CI / review
        ↓
geautoriseerde deployment

De snelle route kan applicaties en jobs bedienen, maar kan geen host-, netwerk- of toegangsgrenzen wijzigen. Beide routes gebruiken dezelfde containers en deploymentlogica, zodat er op termijn geen twee verschillende omgevingen ontstaan.

Verkennend werk krijgt zo snel feedback uit een echte omgeving en formele oplevering houdt een volledige audittrail. Ook AI-agents worden hierdoor bruikbaarder: na een wijziging zien ze sneller het resultaat en kunnen ze meteen verder met de volgende correctie.

Het resultaat: voorspelbare kosten en een kortere feedbackcyclus

Na de migratie daalden de maandelijkse operationele kosten van dit platform met ongeveer 95%. De grootste variabele compute-uitgave veranderde in de vaste capaciteitskosten van één VM. Een paar extra verkenningen of validatieruns starten geen groep zware clusters meer.

Ook de gevolgen voor engineering zijn concreet:

• de lokale omgeving kan meer runtimefouten reproduceren;
• een wijziging kan echte feedback krijgen voordat de volledige CI/CD-route start;
• dependencies, images, jobs en logs staan in één inspecteerbare runtime;
• AI-agents kunnen vaker valideren terwijl het kostenplafond duidelijk blijft.

De migratie verminderde ook het giswerk bij incidenten. Voorheen liep ik bij een fout in de cloud achtereenvolgens code, image, identiteit, rechten en platformstatus na. De meeste problemen zijn nu rechtstreeks te vinden in containerdefinities, joblogs en deploymentrecords.

De grenzen zijn duidelijk

Eén VM vormt één storingsdomein. We bewaren Parquet-bestanden in object storage, maken back-ups van catalogus- en runtimemetadata en zorgen dat containers en configuratie uit geversioneerde artifacts opnieuw kunnen worden opgebouwd. Waar mogelijk zijn jobs idempotent, zodat ze na een storing veilig opnieuw kunnen draaien.

Deze maatregelen ondersteunen herstel en leveren geen ononderbroken beschikbaarheid. Zodra de organisatie zeer lage RTO/RPO, continue beschikbaarheid of meer gelijktijdige verwerking nodig heeft, zijn extra instances, failover en geteste operationele procedures nodig.

De route naar verdere schaal blijft open. De data gebruikt open formaten en de runtime is gecontaineriseerd. Wanneer tijdsvensters, resourcegebruik of gelijktijdige belasting structureel tegen de grens van één machine aanlopen, kan de VM eerst worden vergroot, kunnen daarna workers worden losgekoppeld en kan het platform vervolgens naar meerdere VM’s of Kubernetes gaan. Iedere stap kan op gemeten workloadgegevens worden gebaseerd.

Wat ik hiervan meeneem

Deze migratie leverde een praktische beslisregel op: kijk naar tijdsvensters, resourcegebruik, gelijktijdige belasting, hersteldoelen en de operationele capaciteit van het team voordat je bepaalt hoeveel platformfunctionaliteit nodig is.

Voor de huidige workload van dit dataplatform biedt één VM genoeg rekenkracht en een duidelijk kostenplafond voor verkennend werk. Dat plafond wordt waardevoller naarmate ik sneller met AI-agents werk.

De kostenbesparing van 95% is het meest zichtbare resultaat. De blijvende verandering zit in een korte, heldere ontwikkelcyclus: aanpassen, draaien, het resultaat bekijken en doorgaan.