Self-hosting vs EU sovereign BaaS for a GDPR SME

A self-hosted backend in a European data center and an EU sovereign BaaS can both tick the same GDPR boxes: EU location, European operating company, DPA available (provider side) or up-to-date internal registry (self-hosted side). GDPR has no architectural preference between the two. What really changes is who absorbs the daily operational load: security patch, tested backup, on-call, continuous supervision.

The complete legal framework, GDPR and CLOUD Act, is detailed in our GDPR compliant and EU sovereignbackend guide. What this guide does not go into depth is the real operational cost of each option for a team that does not necessarily have a dedicated SRE. This is the angle of this article.

Self-hosting a Postgres backend shifts complete operational responsibility to your team, not just the server. Concretely, four tasks come up repeatedly: apply Postgres security patches as soon as they are published, and test a backup restoration regularly, not just schedule it. It is also necessary to monitor availability continuously, or accept a longer response time, and rotate secrets and access keys according to a documented schedule.

These tasks never go away, even in self-hosting. You also remain your own technical subcontractor vis-à-vis your host (Hetzner, OVH, Scaleway or other). A DPA must exist with it, and your processing register (Art. 30 GDPR) must document this chain. An SME without a dedicated infrastructure team often underestimates this last point.

An EU sovereign BaaS transfers patching, backup infrastructure and availability monitoring to the provider, under cover of a dated and verifiable DPA (Art. 28 GDPR). It is the operational burden described in the previous point that changes hands, not the legal liability.

The data controller remains you, regardless of the supplier chosen (Art. 24 GDPR). Legal basis for processing, minimization of data collected, notification of violation to the supervisory authority within 72 hours (Art. 33 GDPR): these decisions remain your responsibility. An EU Sovereign BaaS shortens the time needed to produce proof of compliance to a DPO or customer. It does not remove your obligation to have one.

Many teams compare only two options while a third weighs in their real decision: a hyperscaler or a BaaS under American law, configured in a European region. AWS Amplify with a eu-west-1region, or equivalent service, reduces latency and meets data residency requirements. But this does not change the nationality of the company that operates it.

A company incorporated under American law remains subject to the CLOUD Act, regardless of the region chosen by its clients. This point is developed in detail in our guide GDPR compliant and EU sovereign backend and in our dedicated article why the CLOUD Act changes the choice of your BaaS. It counts in the arbitration of an SME, even when this option seems the simplest in the short term.

Here are the three options actually available for an SME today, compared on the criteria that weigh the most in an architectural decision, not just on the region box checked.

The true cost of self-hosting cannot be read on the server bill. It can be read in the engineer time diverted from the product, and in the direct legal exposure in the event of an incident.

A self-hosted SME becomes both data controller and its own technical subcontractor. A missed Postgres patch or a backup never tested becomes directly attributable to the data controller himself (Art. 83 GDPR), without a DPA contractual chain to oppose to document diligence. At an EU sovereign BaaS provider, the same failure remains a real exposure. But it is part of a dated contract that a DPO or an auditor can verify in a few minutes, rather than in an internal history to be reconstructed.

Self-hosting remains relevant for an ETI or a large account which already has an SRE/ops team and functional on-call. It is also true for a sector where sovereignty does not tolerate any chain of external subcontracting: public sector, defense, certain health establishments. Direct control of the physical server takes precedence over the speed of production.

A company that has already invested in an internal Kubernetes or Postgres infrastructure, with the skills to maintain it, amortizes this choice more easily than an SME starting from scratch.

An EU Sovereign BaaS is the right choice for an SME without a dedicated infrastructure team, who needs to demonstrate compliance quickly to a customer or DPO. She therefore prefers to devote her engineering time to the product rather than Postgres patching. It is also the relevant choice for a team that prioritizes speed of release over total control of the stack.

Aurabase does not fix this choice in one direction. The platform exists in EU sovereign managed BaaS, production infrastructure verified in Germany (Nuremberg, Falkenstein) and in Finland (Helsinki) via Hetzner, operated by Aurabase SAS, a company incorporated under French law. It also exists in self-hosting: the repository provides a local Kubernetes cluster (k3d) launched via ./start.sh, and a complete Helm chart for Kubernetes, all under the MIT license.

The same PostgreSQL 16 engine, the same RLS policies and the same SDK apply on both sides: migrating from one model to another does not require rewriting your schema. For a comparison of this self-hosted mode against other mono-binary Rust-native backends (sh0.dev, TrailBase), our article Sovereign self-hosting: Aurabase against Rust-native BaaS explores this architectural angle in detail. This remains focused on the GDPR decision.

Four operational questions to ask yourself before choosing, in addition to the supplier verification checklist in our GDPR guide.

For the complete vendor verification checklist, including legal issues, see our GDPR compliance checklist for a BaaS. For the associated technical security posture, see Aurabase Security page.