Is Supabase GDPR Compliant? The DPA, the Region and the Subprocessor List

When a customer asks whether your app is all right under the GDPR, they are asking about the company running the app, not about their own rights as the person whose data it is. Part of that answer belongs to Supabase, and Supabase has written its half across five separate documents.

Supabase publishes a data processing agreement that takes effect when you accept its terms, a subprocessor document dated 1 June 2026 with twenty-four entries, and a region control that pins your database, Auth and Storage. None of that decides whether your app meets the regulation.

A data processing agreement, in the sense used on this page, is the contract between a company and the vendor that processes personal data on its behalf. The same three letters get used for a data protection regulator, for a power of attorney that survives incapacity, and for a deferred prosecution agreement. None of those is what a customer means when they ask about your DPA. Supabase’s version is called a Data Processing Addendum, and most of the interesting parts are not in it at all: they are in a PDF behind a subscribe form and in a docs page about AWS region codes.

The five documents behind this page are all Supabase’s own, and all were fetched as raw HTML on 3 September 2026: the GDPR guide in the docs, the data processing addendum on the legal pages, the subprocessor document that addendum points at, the regions reference and the security page. Each is quoted or described as it stands, with the read date attached. AxonBuild built none of it, hosts none of it and signed none of it, names no vendor as a recommendation, and gives no legal advice and no verdict on whether a given app meets the regulation.

Is Supabase GDPR compliant, and what does that settle?

Supabase’s own GDPR guide calls a compliant application a shared responsibility: Supabase secures the infrastructure, and the customer is responsible for the application’s data processing activities, consent flows and access controls. Read on 3 September 2026, that sentence is the boundary this whole page works inside.

The exact wording on Supabase’s GDPR compliance guide, read 3 September 2026, is that “Supabase supports building GDPR-compliant applications” and that building one “is a shared responsibility: Supabase secures the underlying infrastructure, while you’re responsible for your application’s data processing activities, consent flows, and access controls.” Two verbs in one sentence, and only the first is Supabase’s.

Supabase’s security page, read the same day, puts the marketing version of it next to the mechanism: “Supabase supports GDPR-compliant deployments. Projects hosted in EU regions keep your primary database data in-region, and a Data Processing Agreement (DPA) is available for customers who need a formal data processing contract under GDPR.”

The role split matters more than either sentence, and it catches small B2B products in a way founders rarely see coming. Clause 2 of the addendum says Supabase acts as processor and the customer as controller. Then it adds one more line: where the customer is itself processing on behalf of its own controller, Supabase acts as a subprocessor. If you sell to businesses and you process their staff data or their customers’ data on their behalf, which is the usual shape when the data sits in your tables for their use, you are somebody else’s processor, and the vendor under you became a subprocessor the day you signed them up; where you decide the purposes yourself, you are a controller for that data instead. That second sentence is the one that decides which box you tick when a customer’s form asks what role you play.

This page settles what Supabase has put its name to. It does not settle two neighbouring questions. A comparison of which builders and platforms sign health-data agreements, and on what plan, sits across all of them rather than in the paperwork of a single backend. And the order a small product meets its own duties, from a lawful basis through to a breach clock, is a separate walk-through and it starts where your vendor’s paperwork stops.

Where the data processing agreement lives, and whether you sign anything

The Supabase DPA sits at one URL, carries a version label and a date, and is signed by nobody. Clause 12.2 says acceptance of the agreement has the same effect as signing the standard contractual clauses. Read 3 September 2026, the document on that page is Version 1, dated 1 August 2026.

The data processing addendum opens by saying it “supplements and forms part of the Supabase Terms of Service” or such other agreement entered into between the customer and Supabase, and that it “is effective as of the Effective Date of the Agreement.” The shorter address supabase.com/legal/dpa still works and returned a 308 redirect to that same page on 3 September 2026.

One document that does not answer this question, despite the name, is Supabase’s privacy notice. Read 3 September 2026, it says Supabase is “the data controller of your personal information” when you use the service, and that content relating to others, including “end users of applications built and managed through the Service”, is used “primarily as a processor” on the customer’s behalf and under the customer’s instructions. The privacy notice is about you. The addendum is about the people using the thing you built.

The practical consequence is worth recording somewhere your buyer can see it. Nothing gets countersigned, so there is no executed copy with two names at the bottom. What you can actually hand a reviewer is a version number, a date, and the date you accepted the terms. Write those three down now, because Version 1 dated 1 August 2026 will not be Version 1 forever, and the reviewer will want to know which text you agreed to.

Two facts sit in Schedule 2 that people usually go looking for later. The party named as the data importer is Supabase Pte. Ltd, with offices at 65 Chulia Street in Singapore and privacy@supabase.io as the contact. The clauses are governed by Irish law under paragraph 1.5, and paragraph 1.6 submits the parties to the courts of Ireland. A Singapore company, Irish courts, and the European clauses sitting in between. That combination is ordinary for a vendor of this shape, and it still catches people out on a first read.

There is one stale answer worth knowing about, because it ranks. A GitHub discussion in the Supabase org still carries, as the answer the page marks, a May 2022 reply telling readers to open a ticket in the dashboard or email support to request the DPA. A comment three months later on the same page points at the self-service legal URL instead, and the latest dated activity anywhere on the page is 24 June 2024. The addendum published today answers the question differently again: there is nothing to request and nothing to sign, because accepting the terms did it.

Clause 3.3 is the part of the document that says what Supabase will not do with your data. It prohibits selling covered data or making it available to a third party for money or other valuable consideration, sharing it for cross-context behavioural advertising, retaining or using or disclosing it for any purpose outside the agreement, retaining or using or disclosing it outside the direct business relationship between the parties, and combining it with personal data received from anyone else. That is five prohibitions inside one clause. Two of them, the purpose limit and the ban on combining, carry the same carve-out for what the applicable data protection laws otherwise permit, and the other three carry none.

The agreement your own customer sends you asks a different set of questions, and the list of vendors it wants named is yours rather than Supabase’s.

Who is on Supabase’s subprocessor list, and what is each one for?

Twenty-four entries, and the page you land on names none of them. As of 3 September 2026, the body of Supabase’s subprocessor page does not name a single subprocessor: it links a dated PDF and offers a form to subscribe to changes. That absence is scoped to that one page.

Supabase’s subprocessor list page says the third-party subprocessors “are indicated in the latest linked Subprocessor List available below” and that the page “is updated with an updated Subprocessor List as our sub-processors change.” Below that sits one link, labelled “Subprocessor List - Updated June 1, 2026”, and a subscribe form. On 3 September 2026, with that page’s whole raw markup read, navigation and footer included, no subprocessor is named anywhere in its body copy.

Here is what is inside the dated subprocessor document, grouped by the description of processing Supabase’s own document gives each entry. Names are spelled as the document prints them.

The count is twenty-four exactly, which is worth writing down rather than rounding, because the document is dated and the next one may not carry the same number. Count the hosting rows and six of those twenty-four are described as providing hosting or serverless data hosting: Amazon Web Services, Cloudflare, Google, Fly.io, Vercel and Upstash. That is more companies with a hosting job than most people picture after clicking one region button, and it is the first thing to reconcile against whatever you told a customer about where the data lives.

One entry is a model provider. Supabase’s own document describes OpenAI, LLC as providing “natural language processing and generation services.” What a model provider keeps after your app calls it, and what you can switch off, is its own subject.

The mechanism around the list is general authorisation, and it has a precondition most people skip. Clause 6.2 grants Supabase general authorisation to engage any subprocessor on the published list. It then requires Supabase to hold a written contract with every one of them carrying data protection obligations that are, in substance, no less protective of covered data than the addendum’s own, and it keeps Supabase liable for how each of them behaves.

Clause 6.3 then describes what happens when the list changes. Supabase offers a subscription on the subprocessor page. The thirty days’ advance notice of a proposed change is conditional on that subscription: the clause says Supabase will give at least thirty days’ notice “if Customer subscribes to receive such updates.” Then you have five days from that notice to object in writing, both parties work in good faith toward a resolution for a period the clause caps at thirty days, and if none is reached you may terminate the portion of the agreement covering the affected services.

The failure mode is an ordinary one. Nobody subscribes, the list changes, and the first anyone hears of it is when a customer asks who else touches their data. The notice clause is real, the notice is opt-in, and the form is three fields on a page most people open once.

Where does your project data actually sit?

One primary region per project, chosen in the dashboard, and the general grouping Supabase recommends is broader than its name. Supabase’s regions reference says the “Europe” general region includes London and Zurich, and its GDPR guide says both have adequacy regimes but neither is an EU member state. Read 3 September 2026.

Start with what the region control covers. Supabase’s GDPR compliance guide says each project “is deployed to a single primary region” and that “your project’s primary Postgres database, Auth service, and Storage objects are hosted in that region.” Choosing a specific region within the EU, the same page says, “pins these services to that exact AWS region.” Auth is on that list, which answers a question people ask separately: the sign-in service sits in the same region as the database.

Now the part the dashboard does not put in front of you. Supabase’s available regions reference, read 3 September 2026, offers three general groupings, one per broad area, and says “For most projects, we recommend choosing a general region.” Picking one hands the placement decision to Supabase, which puts the project wherever inside that area it currently has room. The same page repeats the caution in its own residency section and then gives an example of what a broad area can contain: the Europe general region, it says, includes London and Zurich, which are not EU member states.

The GDPR guide puts the same fact in stronger terms: the “Europe” grouping “also includes London (UK) and Zurich (Switzerland)”, both of which have “GDPR-adequacy data protection regimes, but neither is an EU member state”, and if your requirements call for data to stay within the EU specifically, that page says to choose a specific EU region rather than the general grouping. The GDPR guide then says plainly what a region choice is worth on its own: choosing a region “is a data-location control and does not make your application GDPR compliant on its own.” Both pages carry that limit, in their own words, in the same breath as the recommendation.

If you want the specific end, the regions reference lists seventeen specific regions with their AWS codes, six of them in the European set: West EU (Ireland) eu-west-1, West Europe (London) eu-west-2, West EU (Paris) eu-west-3, Central EU (Frankfurt) eu-central-1, Central Europe (Zurich) eu-central-2 and North EU (Stockholm) eu-north-1. Two of those six are the two the docs name as sitting outside the union. Anyone moving off a grouping for residency reasons is also giving up less than they might think, because the same page notes that read replicas and management through the API do not work with the groupings yet.

Then there is the word in clause 6.1 that a customer’s warranty question tends to land on. Supabase “may Process Covered Data anywhere that Supabase or its Sub-processors maintain facilities”, and where a customer directs a specific geographical region, Supabase “shall ensure that such Covered Data is stored and primarily Processed in that region” unless otherwise required to comply with the customer’s additional instructions, applicable law, or as necessary to provide services the customer requested. The verbs are stored and primarily processed, and three carve-outs follow them. If a customer’s questionnaire asks you to confirm that all processing happens inside the EEA, that clause is what you are answering from, and “primarily” is the word you cannot delete out of it.

Supabase’s GDPR guide closes its own residency section with the list of things that travel out from under a region choice: “Backups, logs, data exported to external systems, Edge Function execution, and sub-processors can affect your data residency and international transfer analysis.” Backups are the one people forget owns a copy of everything, and what a Supabase backup still contains after a delete is a question to settle before promising a customer anything about erasure. If a residency rule with no give in it is what the deal turns on, then the question stops being about configuration and becomes a question about what you own after moving to another backend.

What happens when one of your users asks about their data?

Supabase forwards it to you and does nothing else. Clause 7 says Supabase will promptly notify the customer of a data subject request, that the customer has sole discretion in responding, and that Supabase will not respond except to tell the person the request has been forwarded. The work stays where it was.

The rest of clause 7 commits Supabase to reasonable assistance, taking into account the nature of the services, so that you can meet your own obligation to respond. In practice that means the platform features you already have, not a person doing the search for you.

Schedule 3 adds the fact that makes this section urgent rather than theoretical. The retention period recorded there is “the duration of the Agreement, unless earlier deletion is requested by the Customer in accordance with the functionality of the Services.” Nothing ages out by itself. Every row you ever wrote is still there unless something you built deletes it.

That is the whole of Supabase’s side, which is why this section is a set of directions rather than a procedure. Erasing one person’s records without breaking the rows that reference them is a runbook of its own. Deciding when a whole category of rows goes, rather than one person’s, is a schedule you write once and then follow. And building the file a user is entitled to receive, in a form they can actually use, is a separate job again.

What the addendum commits Supabase to, and what it leaves with you

Four commitments carry dates or clocks: notification of a security incident without undue delay and, where feasible, within forty-eight hours; documentation dated within twelve months in place of a physical audit; a physical audit no more than once per calendar year; and a thirty-day window after the agreement expires to get your data out.

Clause 10 sets the incident clock. Supabase “shall notify Customer in writing without undue delay, and where feasible, within forty-eight (48) hours, after becoming aware of any Security Incident”, sent to the contact details attached to your Supabase account. Check which address that is. If it is a personal inbox from the week you signed up, the clock still runs.

Clause 9 gives diligence two routes. Under clause 9.2 Supabase may satisfy a request with data protection compliance certifications issued by a commonly accepted certification issuer, or with other documentation reasonably evidencing the technical and organisational measures; if that documentation is dated within twelve months of the request and Supabase confirms no known material changes to the controls audited, the customer agrees to accept it in place of a physical audit. Clause 9.3 keeps the physical audit available where the reports do not cover what you need: no more than once per calendar year, on at least thirty days’ written notice, during normal business hours, at your own expense.

Clause 11.2 is the exit. If you ask within thirty days of the agreement expiring, Supabase will provide a copy of all covered data in a commonly used format you request, or self-service functionality to download it. After that retention period ends, Supabase deletes all copies held by it and its authorised subprocessors. The window is generous enough on paper. It assumes somebody still remembers how the export works and still has credentials that open the project, which is a different assumption.

Clause 4 is the mirror of clause 3.3, and it is the longer list. The customer provides data subjects with the required information about the processing, obtains valid consents where the lawful processing needs them, implements technical and organisational measures to give effect to data subject rights and responds within the prescribed timeframes, and gives notice and obtains explicit consent before any sensitive data is collected and processed on a controller’s behalf. The clause then has the customer certify its own compliance with the laws that apply to collecting, using and storing sensitive data. Read straight through, clause 4 is a list of jobs that live inside your app rather than inside Supabase’s, which is why this page keeps pointing somewhere else.

One line in Schedule 3 draws a hard boundary and it is the only health-data commitment quoted on this page: the schedule states that the customer “is not permitted to submit and shall not submit personal data to the Services which would be defined as Personal Health Information under the Health Insurance Portability and Accountability Act of 1996 without first agreeing to sign a separate business associate agreement with Supabase.” Everything downstream of that sentence, the plans it is available on, what the agreement covers and what it leaves out, is answered in the Supabase health-records review.

When these questions arrive as a spreadsheet from a customer rather than as a worry of your own, the answering has a rhythm of its own.

The part none of this settles: an app you did not write

Every document above assumes you can answer questions about your own tables. Which of them hold personal data, whether a delete is a delete, what the logs keep, where an Edge Function sends a request, what an export actually contains. An app assembled by an AI builder rarely comes with those answers attached.

Take the clause 7 case. Supabase forwards the request; you decide what to do about it. Doing anything at all means knowing which tables carry that person, including the ones nobody meant to create: an events table, a webhook log, a cached copy in a storage bucket, a row in an audit trail that was added because it seemed sensible at the time. Nobody who did not write the schema knows that list without going and looking.

Or take clause 6.1’s word. Answering “is all of this processed in the EU” means knowing every outbound call your app makes at runtime, not just where the database sits. An Edge Function that posts to a third-party API is doing a transfer, and it is a transfer Supabase’s region control has no view of.

The split between what the platform operates and what your project decides is the shape of nearly every question on this page, and the Supabase safety review draws that line in more detail. Underneath it sits the narrower question of which rows a signed-in user can actually read back. Neither of those is a GDPR question. Both are why the GDPR question stalls.

Common questions about Supabase and GDPR

How is Supabase’s DPA signed?

It is not signed separately. Clause 12.2 of Supabase’s data processing addendum says acceptance of the agreement has the same effect as signing the standard contractual clauses, and the addendum itself says it supplements and forms part of the Supabase terms of service and is effective as of that agreement’s effective date. Read 3 September 2026, the published version is Version 1, dated 1 August 2026. Record the version and the date you accepted the terms, because that pair is what a reviewer can actually check.

Is Supabase a processor or a subprocessor for your app?

Both, depending on who your customers are. Clause 2 of the addendum says Supabase acts as processor and the customer as controller. It then adds that where the customer is itself processing on behalf of its own controller, Supabase acts as a subprocessor. A consumer app usually sits in the first case. A B2B product holding its customers’ staff or end-user data usually sits in the second, which puts Supabase two steps down the chain.

How many subprocessors does Supabase name, and who are they?

Twenty-four entries as of the document dated June 1, 2026. Six are described as providing hosting or serverless data hosting: Amazon Web Services, Cloudflare, Google, Fly.io, Vercel and Upstash. The rest cover support and communication tools, a status page, monitoring and error tracing, customer insight, a marketplace, feature flagging, account authentication, data analytics, email security, a managed security provider, and OpenAI for natural language processing and generation.

How do you find out when Supabase changes that list?

By subscribing on the subprocessor page, and only by subscribing. Clause 6.3 of the addendum says Supabase will give at least thirty days’ notice of proposed changes to customers who subscribe to receive updates. After a notice you have five days to object in writing, both sides then work toward a resolution within a period the clause caps at thirty days, and if none is reached you may terminate the portion of the agreement covering the affected services.

Does picking a region settle where the data sits?

Not on its own. Supabase’s GDPR guide says that choosing a region “is a data-location control and does not make your application GDPR compliant on its own”, and its regions reference says a general grouping puts the project wherever inside a broad area there is capacity, which can land it outside the jurisdiction you had in mind. The same guide adds that backups, logs, data exported to external systems, Edge Function execution and subprocessors can all affect residency and the transfer analysis.

What does Supabase do if one of your users contacts it directly?

It forwards the request and tells the person it did. Clause 7 of the addendum says Supabase will promptly notify the customer of a data subject request it can associate with that customer, that the customer has sole discretion in responding, and that Supabase will not respond to the person except to advise them that the request has been forwarded. Supabase commits to reasonable assistance so the customer can meet its own response obligation.

How long does Supabase keep your data after the agreement ends?

Thirty days, if you ask. Clause 11.2 says that where the customer requests within thirty days of the agreement expiring, Supabase will provide a copy of all covered data in a commonly used format or self-service functionality to download it, and that on expiry of that retention period Supabase deletes all copies processed by it and its authorised subprocessors. During the agreement, Schedule 3 records the retention period as its full duration unless earlier deletion is requested.

Can you hand Supabase’s DPA to a customer who asks for yours?

They are two different documents doing two different jobs. Supabase’s addendum covers what Supabase does with data you send it, and it names Supabase Pte. Ltd as the importer, with Irish law and the courts of Ireland chosen in Schedule 2. Your customer is asking about what your company does with data they send you.

The agreement a customer sends you is its own subject, with its own vendor list to fill in and its own set of promises attached to your name rather than Supabase’s.