You’ve decided your data should live in Europe. On European infrastructure, under European jurisdiction. Great!
Now comes the harder question: How do you actually build a data platform on your EU cloud?
We’ve spent the past year answering exactly that question, first for our own clients, then by productizing the answer as Databaas. This post gives you some tools to get started yourself. Which cloud to pick, which tools to use, and how to wire them together.
Step 1: Pick a European cloud
Everything starts with infrastructure. If your compute and storage run on AWS, Azure, or GCP, your “sovereign data platform” is a sovereign sticker on American hardware. EU regions don’t change the legal picture: US-owned providers fall under the US CLOUD Act regardless of where the datacenter stands, admitted by Microsoft.
We’ve done the homework here, hands-on:
- In European Cloud Providers Compared: A Hands-On Terraform Test, Stijn signed up at OVHcloud, Scaleway, Hetzner, and STACKIT, deployed real infrastructure with Terraform, and scored them on developer experience. Short version: Scaleway for developer experience, OVH for breadth of services, Hetzner for price.
- Also an SO to the Dutch clouds that have been stepping up their game recently: Soever (for governments), RAM-IT (for healthcare), Tilaa, Intermax, and then I’m probably missing many others.
- In European Cloud for Startups, we mapped out the startup credit programs of the European providers, because yes, they have those too.
- And if you want to get practical immediately: Getting started with OpenTofu/Terraform on OVH.
The takeaway for a data platform specifically: you need three things from your cloud. S3-compatible object storage, a way to run containers (managed Kubernetes or beefy VMs), and a managed PostgreSQL for the metadata of your tools. Scaleway and OVH give you all three as managed services. Hetzner gives you cheap compute and object storage, but you’ll run Kubernetes and Postgres yourself.
Step 2: Accept that the big platforms won’t come with you
Say you’ve picked Scaleway. Now you want to put your familiar data platform on top of it.
You can’t.
| Platform | Runs on |
|---|---|
| Databricks | AWS, Azure, GCP |
| Snowflake | AWS, Azure, GCP |
| BigQuery | Google Cloud only |
| Microsoft Fabric | Azure only |
None of the big four data platforms can be deployed on a European cloud. Not on OVH, not on Scaleway, not on Hetzner, not on STACKIT. They are built on, and commercially tied to, the American hyperscalers. BigQuery and Fabric don’t even leave their home cloud.
The vendors know this is becoming a problem, which is why you’ll hear a lot about “sovereign regions” and “EU data boundaries.” But those constructions still run on hyperscaler infrastructure, with a control plane operated by a US company. If your requirement is European infrastructure, European jurisdiction, the mainstream platforms are simply not an option.
The good news: everything those platforms do, open source does too. Often even with the same engines under the hood!
Step 3: Select your tools, layer by layer
A data platform is really six or seven components in a trench coat. For each layer there’s a mature open-source option that runs anywhere containers run. Below is what we chose for Databaas, and the alternatives we weighed.
Storage: Apache Iceberg on S3-compatible object storage
Purpose: Where your data lives.
Your tables live as open files in a bucket you own. We use Apache Iceberg as the table format: schema evolution, time travel, ACID transactions, all on plain object storage.
Alternatives:
- Delta Lake is technically excellent, but its center of gravity is the Databricks ecosystem.
- Apache Hudi is strong for streaming-heavy workloads but has a smaller community.
Iceberg has become the neutral industry standard. Even Snowflake and Databricks now support it, which tells you everything about where the market is heading. Choosing Iceberg means your data outlives any tool choice you make on top of it.
Catalog: Lakekeeper
Purpose: Keeps track of what data you have.
Iceberg tables need a catalog that tracks schemas, snapshots, and permissions. We use Lakekeeper, an open-source Iceberg REST catalog written in Rust: fast, lightweight, self-hostable, with fine-grained access control.
Alternatives: Apache Polaris (Snowflake’s open-sourced catalog) and Project Nessie are solid options. Unity Catalog is open source on paper, but in practice it pulls you into Databricks’ orbit. Lakekeeper won for us on simplicity of self-hosting and its permission model.
Query engine: Trino & DuckDB
Purpose: Ask questions, get answers quickly.
Trino runs distributed SQL directly on your Iceberg tables: joins and aggregations across billions of rows, no copies, no extracts. It’s the same engine class that powers Starburst and Athena, so your analysts get a familiar, fast SQL experience.
Alternatives:
- ClickHouse is blisteringly fast but wants to own the data in its own format, which undermines the open-lakehouse idea.
- Apache Spark is the workhorse for heavy transformations but overkill as an interactive engine.
And for most data, honestly, DuckDB will take you further than you think. We wrote a whole starter guide on DuckDB + Superset.
DuckDB for 80% of the work, Trino for the other 20% when you need access at scale.
Orchestration: Apache Airflow
Purpose: Moves data automatically, on schedule.
Pipelines need scheduling, retries, and lineage. We run managed Apache Airflow, and crucially, your DAGs live in your own Git repos. Your pipeline code stays your code.
Alternatives:
- Dagster has a lovely developer experience and asset-based model;
- Prefect is elegant for Python-native teams.
We chose Airflow for the ecosystem: every data engineer knows it, every tool integrates with it, and hiring for it is easy. Boring and stable are features in orchestration.
Identity & governance: Zitadel
Purpose: One login, controlled access everywhere.
One login for everything, or nobody will use the platform securely. Zitadel handles SSO, MFA, and role-based access across all components, and it can federate with the identity provider you already have (Entra ID, Google Workspace).
Alternatives:
- Keycloak is the veteran here and works fine, but it’s operationally heavy.
- Authentik is a nice lightweight option, but didn’t cover all our needs.
Zitadel, itself a European (Swiss) open-source project, hit the sweet spot of modern architecture and multi-tenancy.
Notebooks: JupyterHub + Marimo notebooks
Purpose: Explore, prototype, experiment.
Analysts and data scientists get a managed workspace via JupyterHub, with Marimo for reactive, reproducible, git-friendly notebooks that don’t rot the moment you close them. Marimo notebooks are easily promoted to production and have great integration with your AI weapon of choice (e.g. Claude, OpenAI)
Alternatives:
JupyterHub is the self-hosted standard; Marimo is the modern upgrade on top.
Dashboards: Apache Superset
Purpose: Charts and KPIs for everyone.
Apache Superset connects to Trino and gives the whole organization charts, dashboards, and SQL exploration, embeddable and shareable.
Alternatives:
- Metabase is friendlier for non-technical users but the open-source edition is more limited;
- Grafana shines for operational metrics, less for business analytics;
- Lightdash is great if you’re deep into dbt, but does not cover all our integration needs.
Superset offers the most capability without licensing surprises.
Step 4: Build it yourself
Everything above is open source. You can absolutely assemble this yourself, and for teams with platform engineering capacity, it’s a legitimate route.
The high-level recipe:
- Provision the foundation. Managed Kubernetes, an object storage bucket, and a managed PostgreSQL on your European cloud of choice. Define all of it in OpenTofu/Terraform from day one, our provider comparison shows what to expect per cloud.
- Deploy the components. Every tool in this post ships an official Helm chart: Lakekeeper, Trino, Airflow, Zitadel, Superset, JupyterHub. Get each running against a Postgres database and the shared bucket.
- Wire up identity. Configure Zitadel as the OIDC provider and connect every component to it. This is fiddlier than it sounds; each tool has its own ideas about groups and roles. Skip this if you don’t need a centralised authorisation matrix.
- Connect the data plane. Point Trino and Airflow at Lakekeeper, register the bucket as an Iceberg warehouse, connect Superset to Trino, and give JupyterHub credentials to the catalog.
- Make it production-grade. TLS everywhere, network policies, backups for every Postgres instance, monitoring and alerting, failover on all components, and a tested upgrade path for eight-plus moving parts.
Steps 1 and 2 are a good week of work. Or just give this post to Opus 5, and let it take the wheel for a quick POC within hours.
Steps 3 to 5 are where the real time goes, and that never really ends: Trino releases roughly every few weeks, Airflow and Superset have their own cadence, and security patches don’t wait for your sprint planning.
Realistically, you’re signing up for two full time platform engineers, at a minimum.
Or: get it as a managed platform
That ongoing operational load is exactly why we built Databaas: the full stack described above: Lakehouse, pipelines, governance, dashboards, notebooks, and agents. Pre-integrated, EU-hosted, battle-tested and fully managed by our team in Utrecht.
The principles stay the same as when you build it yourself. Your data stays in your own bucket, in your own cloud, in open formats. Your DAGs and notebooks stay in your own repos. Everything is open source, so if you ever want to leave, you export your Iceberg tables and pipelines and walk away. No lock-in. And that’s the whole point. We just handle the wiring, the upgrades, and the 3 a.m. pages.
One platform, one contract, one team to call. And when something breaks, you talk to the people who built it.
Want to see it running on your data? Book a demo! Or if you’d rather build it yourself and want a head start, reach out at hello@wolk.work. We’re happy to help you either way.
