Dat klopt niet. Wil je vandaag een compleet dataplatform op Europese infrastructuur neerzetten, met een lakehouse, pipelines, governance, dashboards en notebooks, dan liggen alle onderdelen gewoon klaar.
Volwassen, open source, en op petabyteschaal in productie bij bedrijven die je kent. De vraag is dus niet of het kan, maar welke onderdelen je kiest en hoe je ze met elkaar verbindt.
Stap 1: Begin bij de infrastructuur
Draaien je computer en storage op een Amerikaanse hyperscaler, dan is je soevereine dataplatform vooral een sticker. Een EU-regio verandert de juridische werkelijkheid niet: Amerikaanse aanbieders vallen onder de CLOUD Act, ongeacht waar het datacenter staat. Microsoft bevestigde dat in 2025 nog tijdens een hoorzitting in de Franse Senaat.
Gelukkig is het Europese aanbod serieus geworden. Voor een dataplatform heb je maar twee dingen nodig van je cloud:
-
S3-compatibele object storage, waar je tabellen komen te staan
-
Managed Kubernetes
Meerdere Europese providers leveren die twee inmiddels out of the box. Daarnaast is er een laag Nederlandse aanbieders die zich per sector specialiseert, van zorg tot overheid. Die kennen de compliance-eisen van binnenuit, en de lijnen zijn er korter dan je bij een hyperscaler ooit krijgt. Kijk ook eens naar de lokale opties!
Praktische tip: leg je infrastructuur vanaf dag één vast in code, met OpenTofu bijvoorbeeld. Een exitplan zonder verplaatsbare code blijft vaak alleen bij een plan.
Stap 2: Realiseer je dat de grote platformen niet mee gaan
Hier komen de meeste teams te laat achter. Je hebt je Europese cloud gekozen, en nu wil je je vertrouwde dataplatform erop zetten. Dat kan niet. De grote commerciële dataplatformen draaien uitsluitend op de Amerikaanse hyperscalers, en een deel verlaat de eigen thuiscloud zelfs helemaal niet. De sovereign regions die de leveranciers hier tegenover zetten zijn niet waardeloos, maar het draait nog steeds op hyperscaler-infrastructuur met een control plane in beheer bij een Amerikaans bedrijf.
Even een misverstand uit de weg: dit gaat niet over data formats. Open table formats worden inmiddels prima ondersteund door de grote platformen, dus als onderscheidend criterium is dat achterhaald. Het gaat om de laag eromheen. Het control plane, je pipelines, je governance en de jurisdictie waaronder dat alles valt.
En daar zit de opening. Want alles wat die platformen doen, kan open source ook.
Stap 3: Kies de onderdelen, laag voor laag
Een dataplatform is in de kern zes of zeven componenten in een lange jas. Voor elke laag bestaat een volwassen open-source optie die draait waar containers draaien.
Storage: Je tabellen staan als open bestanden in een bucket die van jou is, met schema evolution, time travel en ACID-transacties. Apache Iceberg is hier de neutrale standaard geworden, ontstaan bij Netflix en op petabyteschaal in gebruik bij onder meer Apple. Delta Lake en Apache Hudi zijn de bekendste alternatieven.
Catalog: Houdt schema's, snapshots en rechten bij. Lakekeeper, Apache Polaris en Project Nessie zijn de opties, allemaal zelf te hosten en met fine-grained access control over meerdere query engines heen. Kijk goed naar wie de projectgovernance in handen heeft, want dit is bij uitstek de plek waar lock-in ontstaat.
Query engine: Trino draait gedistribueerde SQL direct op je tabellen, zonder kopieën of extracts. Het is gewoon SQL, dus je analisten kunnen er vanaf dag één mee overweg. Wees wel eerlijk over je datavolume: de meeste workloads passen prima op één machine, zonder cluster, met bijvoorbeeld DuckDB.
Orchestration: Scheduling, retries en lineage. Apache Airflow is de standaard, Dagster is de moderne uitdager. Belangrijker dan de toolkeuze is dat je pipelinecode in je eigen Git-repository staat. Code die alleen in de UI van je leverancier bestaat, ben je bij een exit kwijt.
Identity: Eén login voor alles, anders gebruikt niemand het platform veilig. Je wilt SSO, MFA en role-based access control over alle componenten heen. Keycloak is de veteraan en operationeel wat zwaarder, Zitadel is moderner en zelf een Europees open-sourceproject. Authenticatie is daarmee geregeld, autorisatie nog niet: wil je per gebruiker precies vastleggen welke data en acties zijn toegestaan, dan zet je daar een policy-laag naast, zoals OpenFGA of OPA.
Dashboards: Apache Superset verbindt met Trino en geeft de organisatie grafieken, dashboards en SQL-exploratie. Metabase is vriendelijker voor niet-technische gebruikers, Grafana blinkt uit in operationele metrics.
Notebooks: JupyterHub is de self-hosted standaard. Marimo is daar de moderne upgrade op: reactieve notebooks die als gewone Python-bestanden op schijf staan, dus git-vriendelijk en eenvoudig naar productie te promoveren. De gepolijste alternatieven zijn vrijwel allemaal Amerikaanse SaaS.
Zeven lagen, en per laag meerdere volwassen opties. Geen daarvan is een compromis of een Europees alternatief dat er bijna is. Het zijn de projecten die de rest van de wereld ook gebruikt.
Stap 4: Zet het in elkaar
Zet eerst het fundament neer: managed Kubernetes, een object storage bucket, alles in Terraform code. Deploy daarna de componenten, want elke tool levert een officiële Helm chart. Gebruik ArgoCD voor GitOps. Koppel je identity provider via OIDC aan elk component, en leg je autorisatieregels als code vast in OPA of OpenFGA, zodat rechten centraal staan in plaats van per tool opnieuw ingericht. Wijs vervolgens je query engine en orchestrator naar de catalog, registreer de bucket als warehouse, en sluit je dashboards en notebooks aan.
Dat eerste Helmcharts is een goede week werk, en met wat AI-assistentie heb je binnen een dag wel een POC. Daarna komt het echte werk: Identity management, autorisatie, TLS, network policies, backups, monitoring, failover, een getest upgrade path etcetera, etcetera. Elk project heeft zijn eigen release cadence, en security-patches wachten niet op je sprintplanning.
Dat hoeft je niet tegen te houden, want het is platformbeheer, hetzelfde werk dat elk serieus IT-team al doet. Wel iets om vooraf eerlijk te begroten, naast de licentiekosten van het alternatief. In veel migratiediscussies gaat het uitsluitend over de prijs van software en nauwelijks over de prijs van beheer.
Praktische keuzes vs. Contractuele afspraken
Soevereiniteit koop je niet met een vinkje in een contract. Contractuele afspraken zijn óók belangrijk, maar het blijft vooral een architectuurkeuze.
En je bouwt hem in door drie dingen in eigen hand te houden:
-
Je data, in je eigen bucket, in open formats, keys door jou beheerd
-
Je pipelinecode, in je eigen repository
-
Je infrastructuur, in code die je elders opnieuw kunt uitrollen. Cloudagnostisch.
Doe je dat, dan is (bijna) elke tool vervangbaar. En je hoeft nergens op te wachten, want de onderdelen liggen er vandaag al.
Buy or build?
Alles hierboven kun je zelf assembleren, en voor teams met platform-engineeringcapaciteit is dat een prima route. Bij Databaas leveren we deze stack als één pakket, draaiend op de Europese cloud van jouw keuze of op je eigen Kubernetes-cluster. Wij nemen de deploys, upgrades en security-patches over. Jij houdt de sleutels, want je data staat in jouw bucket en je pipelinecode in jouw repository. Geen lock-in, dus je kunt weg wanneer je wilt. We helpen je zelfs met vertrekken. Je zult het niet willen, maar het kan.
Databaas x Data Expo
Op 9 en 10 september staan we op Data Expo in de Jaarbeurs Utrecht. Loop langs als je wilt weten hoe zo'n platform er voor jouw organisatie uitziet, en hoe snel het kan staan. Ik praat je er graag over bij.
Deze blogpost is een bijdrage van Databaas, het soevereine data- en AI-platform op open source en open standaarden. Databaas levert een complete datastack, van lakehouse en pipelines tot dashboards, notebooks en AI, draaiend op Europese infrastructuur en onder Europees recht. Gebouwd en beheerd vanuit Utrecht door Wolk. Meer inspiratie vind je op www.databaas.eu of bezoek Databaas tijdens Data Expo.
Auteur: Stijn Meijers, Co-founder, Chief Product Officer @ Wolk & Databaas
