GDPR Database Hosting: What an EU-Friendly Setup Needs

GDPR database hosting is less about a magic "GDPR-compliant" label and more about a few concrete things: knowing where personal data is stored and processed, having a data processing agreement with your host, controlling transfers outside the EU, securing the data, and being able to find, export and delete a person's data on request. Hosting your database in an EU region makes several of these easier, but it does not do the work for you.

This guide explains what the regulation asks of a database setup, in developer terms, and ends with a checklist. It is not legal advice; involve your legal or privacy lead for your specific case.

#What GDPR actually says about database hosting

The GDPR does not say "store data in the EU". It says personal data may leave the European Economic Area only under certain conditions (Chapter V, Articles 44 to 49): an adequacy decision for the destination country, appropriate safeguards such as Standard Contractual Clauses, or narrow exceptions.

For the United States, the European Commission adopted the EU-US Data Privacy Framework adequacy decision in July 2023. In September 2025 the EU General Court dismissed a challenge to it (the Latombe case), though an appeal to the Court of Justice was announced. Its predecessors, Safe Harbor and Privacy Shield, were both struck down by the Court of Justice. That history is why many European companies prefer to keep personal data with EU-hosted providers: it removes a legal dependency that has changed twice before.

Beyond transfers, several articles directly affect how you run a database:

#Controller and processor

When you run an app on a hosted database, you are usually the controller (you decide why and how personal data is processed) and the host is a processor (it processes data on your behalf). The processor's own suppliers, such as the data center operator or e-mail provider, are sub-processors.

What to get from any host:

• A data processing agreement (DPA) that covers Article 28 terms.
• A list of sub-processors, with where they are located and what they do.
• A clear statement of where data is stored: database, backups, logs, files.

StitchDB publishes a DPA and a sub-processor list on its site. Read both, the same as you would for any vendor.

#Data residency: more than the database

"Our database is in Frankfurt" is a common answer that misses half the picture. Personal data lives in more places:

• The primary database
• Backups and WAL archives
• Read replicas, which may be in other regions
• File storage for uploads and avatars
• Logs that contain IP addresses, e-mails or request bodies
• E-mail delivery for auth e-mails
• Preview and staging databases with copies of production data
• Analytics and error tracking that capture user identifiers

For each, know the location and who processes it.

On StitchDB, you choose a region when you create a project, and it decides where the database and files are stored. It cannot be changed later. StitchDB's data centers are in Falkenstein and Nuremberg in Germany and Helsinki in Finland. According to the docs and pricing FAQ, files are stored in EU object storage, backups are encrypted and kept in the EU, and logs are kept in EU object storage encrypted with AES-256. Check the sub-processor list for services such as e-mail delivery.

#Security measures that matter (Article 32)

Article 32 asks for security "appropriate to the risk". For a database, a reasonable baseline:

• Encryption in transit. Require TLS for every connection. On StitchDB, Postgres connections must use TLS 1.2 or 1.3; unencrypted connections are refused, and all APIs are HTTPS.
• Encryption at rest for backups. StitchDB backups use AES-256.
• Access control. Separate keys for clients and servers, least-privilege roles, Row Level Security for data reached through an API. See Postgres Row Level Security.
• Network restrictions on direct database access where possible. StitchDB lets you allow-list IPv4 addresses for Postgres connections from the Pro plan.
• Ability to restore (Article 32 explicitly mentions restoring availability after an incident). Point-in-time recovery and tested restores cover this. See Backups.
• Audit trail of who did what. StitchDB keeps an audit log of team actions.
• Two-factor authentication for everyone with dashboard access.

#Erasure, retention and backups

The right to erasure is where database design meets GDPR most directly.

Design for deletion. Use foreign keys with on delete cascade from the user to their data, so deleting the user removes their rows:

create table public.profiles (
  id uuid primary key references auth.users on delete cascade,
  display_name text,
  phone text
);

Pseudonymize what you must keep. Invoices may need to be kept for tax reasons. Keep the invoice, remove or replace the personal fields:

update public.invoices
set customer_name = 'deleted user', customer_email = null
where customer_id = $1;

Set retention for logs and events. Delete old rows on a schedule:

select cron.schedule('purge-events', '0 3 * * *',
  $$delete from public.events where created_at < now() - interval '90 days'$$);

Backups. Deleting a row does not remove it from existing backups. The common, defensible approach is a fixed backup retention, so deleted data ages out of backups within a known period, and a process to re-apply deletions if a backup is ever restored. Know your retention: on StitchDB, point-in-time recovery covers 24 hours on Free, 7 days on Pro, 14 on Scale and 30 on Enterprise, and daily restore points follow the plan's retention. If you turn on a table's recycle bin, deleted rows are kept for the same period, so factor that in.

#Copies of production data

Preview and staging environments are a frequent GDPR blind spot: a developer copies production to test a migration, and real customer data now lives on a laptop.

Better options:

• Seed test environments with fake data.
• Mask personal data when copying. StitchDB's preview branches can copy production with e-mails, names, phone numbers, addresses, IPs and tokens replaced; the masking runs inside production's own query, so real values never leave it. The docs are clear that this is a safeguard, not anonymization in the legal sense: review free-text and JSON columns.

#Access and portability

Build the export path before the first request arrives. A function that returns everything about a user as JSON covers most access requests:

create function public.export_my_data() returns jsonb
language sql stable security invoker
as $$
  select jsonb_build_object(
    'profile', (select to_jsonb(p) from public.profiles p where p.id = auth.uid()),
    'orders',  (select coalesce(jsonb_agg(o), '[]') from public.orders o where o.user_id = auth.uid())
  )
$$;

Because it runs with the caller's rights (security invoker), Row Level Security still applies.

For the whole project, StitchDB's export produces one archive with the database dump, auth users, files and settings, in open formats.

#A checklist

• Map where personal data lives: database, backups, replicas, files, logs, e-mail, analytics, test copies.
• Choose hosting regions deliberately, and check that replicas and backups stay in the same jurisdiction.
• Sign the host's DPA and record it in your records of processing.
• Review the sub-processor list and subscribe to changes.
• Enforce TLS and restrict direct database access.
• Turn on RLS for every table reachable by an API.
• Design user deletion with cascades and pseudonymization.
• Set retention for logs, events and backups, and document it.
• Mask or fake data outside production.
• Test an export and a deletion end to end.
• Write down the breach response: who decides, who notifies, within 72 hours.

For a broader look at EU-hosted backends, read EU-Hosted Backend as a Service.

#FAQ

#Do I have to host in the EU to comply with GDPR?

No. Transfers outside the EEA are allowed under adequacy decisions or safeguards. EU hosting simplifies compliance and reduces exposure to future legal changes.

#Is a US company's EU region the same as an EU provider?

Not always. Data can be stored in the EU while the provider is still subject to US law. Some teams accept that under the Data Privacy Framework; others prefer EU-based providers. Assess it with your legal team.

#Does encryption make data anonymous?

No. Encrypted personal data is still personal data. Encryption reduces risk; it does not remove GDPR obligations.

#What about backups after an erasure request?

Common practice is a fixed backup retention so data ages out, plus re-applying deletions if you restore. Document it.

StitchDB's data centers are in Germany and Finland. Read about security, or create a project in Germany or Finland.