GDPR and Supabase backups: where your copies actually live

Two searches bring people here: “is Supabase GDPR compliant” and “where is the Supabase DPA”. Both have short answers, and both stop one step early. A project pinned to Frankfurt with a signed DPA still has copies of its data somewhere else the moment anyone backs it up — and Supabase’s own GDPR guide lists backups first among the things that change your residency analysis. The short answers come first below; then what each backup option, ours included, does to the picture. This is a technical guide, not legal advice.

Is Supabase GDPR compliant?

Supabase answers this carefully, and the care is the point. Its GDPR guide says the platform supports building GDPR-compliant applications under a shared responsibility model: Supabase secures the underlying infrastructure; you are responsible for your application’s data processing activities, consent flows, and access controls. That is not a dodge. Compliance is a property of an application and the processes around it, and no vendor can hand it over as a feature.

What Supabase does hand over is the set of controls an assessment needs: pinning a project to a specific EU region, a Data Processing Agreement, a published sub-processor list, and — for Team and Enterprise customers — a SOC 2 report downloadable from the Legal Documents section of the organization dashboard. The same guide adds the sentence this page is built on: choosing a region is a data-location control and does not make your application GDPR compliant on its own, because backups, logs, data exported to external systems, Edge Function execution, and sub-processors can all affect your residency and international transfer analysis.

Which Supabase regions are in the EU

Each project is deployed to a single primary region, and its Postgres database, Auth service, and Storage objects are hosted there. Supabase offers a general “Europe” region that places the project wherever capacity allows, and specific regions that pin it to one AWS region. The general grouping includes two locations that are in Europe but not in the EU, which is exactly the distinction a data residency requirement turns on:

The UK and Switzerland both hold EU adequacy decisions, so transfers to London or Zurich are not the problem that transfers to the US are. But “adequate third country” and “EU member state” are different boxes on a DPIA, and a policy that says “data stays in the EU” is not met by a project the general region placed in London. If EU-only is the requirement, pick a specific EU region from the regions list at project creation; a project’s region cannot be changed afterwards without migrating it.

Where to find Supabase’s DPA and sub-processor list

The Data Processing Agreement is published at supabase.com/legal/dpa. It incorporates the EU Standard Contractual Clauses — the modules for controller-to-processor and processor-to-sub-processor relationships — and names the GDPR, Swiss data protection law, and US state privacy laws as the regimes it covers. The sub-processors Supabase relies on are listed at the sub-processor list, which offers a subscription for change notices; under the DPA, objecting to a new sub-processor is a defined process, so the subscription is worth having if you rely on the list. The SOC 2 report is separate: available to Team and Enterprise plan customers from the Legal Documents section of the organization dashboard.

The step everyone skips: a backup is a copy

Once the project is pinned and the DPA is on file, the residency picture is complete for exactly as long as nobody makes a copy. Every backup — Supabase’s own, a nightly pg_dump, a hosted service — is personal data being processed somewhere, by someone. The GDPR consequences depend on who and where. A dump you run yourself onto storage you control adds no new party; the storage provider is already your processor. A third party that runs the backup for you is a processor (Article 28, so it needs a contract), and so are its sub-processors. And whenever a recipient — a vendor, a vendor’s sub-processor, a cloud provider — is established outside the EEA, sending the data to it is an international transfer (Chapter V, so it needs a mechanism such as the SCCs plus a transfer assessment). Note the two boundaries that trip people: the transfer test is about the EEA, not the EU alone, and it applies to recipients, not to where your own staff happen to sit. None of this is exotic; it is the analysis you did for Supabase itself, repeated for each party that touches the copies. Four questions cover it:

1. Where do the copies rest? Which bucket, in which region, in whose account. A vendor’s “EU storage” and a bucket you own in eu-central-1 are both EU, but only one of them still exists after you cancel.
2. Where do the bytes transit? The machine that runs the dump, and — if the tool restore-tests backups — the machine the data is restored into for the test. This is the question hosted vendors answer least often.
3. Who can read them? Whether the vendor holds the storage credentials or encryption keys, and whether the archive format is open enough to restore without the vendor.
4. How do retention and erasure work? Who decides when old copies are deleted, and what happens to a data subject’s erased records when a backup taken before the erasure is restored. More on that below.

How the backup options compare on residency

The same four questions, answered for the options people actually weigh. Competitor cells come from their public documentation as of the date at the bottom; ours from our privacy policy and current infrastructure, with the uncomfortable part left in.

Two patterns fall out. Vendors that store the copies for you in the EU — ReviveDB, BackProve, SimpleBackups on its default EU servers — answer the resting-place question in the EU, at the price of the copies living in their account under their keys. Where their workers run is a separate question their pages answer unevenly: SimpleBackups names Germany and Finland; ReviveDB names Amsterdam and adds, to its credit, that its host is US-based so EU-only processing is not guaranteed; BackProve’s security page states storage location only. Ask before assuming. Tools that write into a bucket you own — DIY, Databasus, BackupDrill — keep custody with you, and then the residency question moves to wherever the tool runs. For the CLI and for DIY that is your machine; for our hosted service it is our worker, which today is in the US.

What BackupDrill does with your data, exactly

For the contents of your database and Storage files we are a processor: we touch that data only to run the backups and restore drills you configured, and for nothing else. The mechanics, so you can put them in a DPIA without guessing: you give us a database connection string and credentials for a bucket you own; both are stored sealed-box encrypted. On schedule, our worker connects to your project, runs a version-matched pg_dump, and streams the archive straight into your bucket — during a backup nothing is written to disk on our side. Storage files join the same snapshot once you add the project’s Storage S3 keys on the project page; without them a backup is database-only. The restore drill is different, and worth stating precisely: the worker downloads the latest archive to a temporary directory on its own disk, restores it into a disposable Postgres running in Docker, runs the checks, then deletes the directory and the database. So drill data does touch our disk, briefly, in the clear. Alert emails go through Resend.

The worker currently runs in the United States (Virginia). So while the copies rest in whatever EU region you chose for your bucket, the bytes transit US infrastructure in memory during each backup, and during each drill the archive sits briefly on that worker’s disk and the data exists, decrypted, in a database there until the drill finishes. We are stating that plainly because it is the kind of detail vendors leave out and assessors find later. If EU-only processing is a hard requirement, the open-source CLI runs the same engine — same snapshot layout, same manifest, same drill — on a machine you place in the EU, with no third party in the path. If you want the hosted service anyway and need a signed DPA or a documented position on transfers, email support@backupdrill.com before relying on it, not after.

Retention, erasure, and the backup you cannot edit

Two GDPR principles pull against each other here. Storage limitation says personal data is kept no longer than necessary; integrity and availability (Article 32 names the ability to restore access to data after an incident) say you had better have a backup. Backups are also practically immutable — you do not open an archive to delete one person’s rows — which collides with the right to erasure. The approach supervisory authorities have generally accepted, and the one most policies document, has three parts: keep backups for a bounded, written retention period; treat a subject’s erased data as erased even while it survives in a backup inside that period; and make sure a restore does not quietly resurrect it, which means keeping a log of erasures to re-apply after any restore. Write the period and the procedure into your records of processing, and you have an answer rather than an exposure.

With a bucket you own, the retention half is a lifecycle rule you set — 30 days, 90 days, whatever the policy says — and nobody else’s deletion schedule. BackupDrill never deletes objects from your bucket: the rotation you see in the dashboard is a record count, not a delete, so expiry is entirely yours to configure and audit. The bucket guides show the lifecycle setting for S3, R2, and B2. And because every snapshot is a plain pg_dump custom-format archive with a manifest, the re-apply-erasures step after a restore is ordinary SQL against a database you control, not a support ticket.

The short version

Pin the project to a specific EU region, not the general Europe grouping. Get the DPA on file and subscribe to the sub-processor list. Then do the same analysis for every backup copy: where it rests, where it transits, who holds the keys, how it expires. If the answer has to be “EU, EU, us, us”, run the backup yourself on an EU machine into an EU bucket — the backup options guide covers the DIY route and the CLI. If “in our EU bucket, drilled weekly, worker in the US” fits your assessment, the hosted service is one project free and proves the copies restore.

FAQ