← Back to home

Supabase DPA — what it covers, what it does not, and where an EU-native alternative fits

Supabase provides a signed GDPR Data Processing Addendum with Standard Contractual Clauses. A DPA is essential — but it is a contract, not a shield against statutes. Here is how the Supabase DPA works, what your legal team should check for, and why regulated buyers still want an EU-parent processor.

What a DPA is (and what it is not)

A Data Processing Addendum is the Article 28 contract between you (the controller) and your processor. It defines the scope of processing, the security obligations, the sub-processor rules, breach-notification timelines, transfer mechanisms for non-EEA destinations, and the return/deletion of data at end of contract.

What a DPA is not: an override of statutes that bind the processor. If your processor is subject to the CLOUD Act, FISA §702, or a national-security letter regime, the DPA cannot promise the operator will refuse a lawful order in the jurisdiction that binds them. This is why "we have a DPA" and "we are outside US reach" are different claims.

The distinction matters for procurement. A private-sector B2B SaaS with private-sector customers can usually accept SCCs + DPA as sufficient. A processor of health, legal, defence, or public-sector data often cannot — because the sectoral rules (BRAO for German lawyers, GoBD for German tax records, HDS for French health) add residency-plus-jurisdiction obligations on top of GDPR.

How to sign the Supabase DPA

Supabase Inc. makes their GDPR Data Processing Addendum available via the dashboard for paid plans; a copy is also linked from the compliance page. It is a click-to-accept contract for the standard terms; custom modifications (e.g., additional data-subject notification obligations, insurance requirements) are negotiated separately for Enterprise tier.

  • ▸Access — dashboard → Organization Settings → Data Processing Agreement (paid plans).
  • ▸Format — click-to-accept for standard terms; PDF export available.
  • ▸Counter-signature — not required for standard terms; required for custom modifications.
  • ▸Effective date — the date you click accept.
  • ▸Retention — Supabase retains the accepted version and the ID of the accepting user for audit.

Standard Contractual Clauses in the Supabase DPA

Because Supabase Inc. is a US entity and AWS (its infrastructure provider) is also US, personal data flowing to a Supabase project is deemed transferred to a non-adequate country under GDPR Chapter V. The transfer mechanism the Supabase DPA uses is the EU Commission's 2021 Standard Contractual Clauses (Module 2: controller to processor), with the EU-US Data Privacy Framework as the primary basis where the processor is DPF-certified.

The SCCs impose specific obligations on the recipient: notify the controller if requests from public authorities are received (Clause 15), assist with data-subject rights (Clause 10), use only approved sub-processors (Clause 9), and undergo audits (Clause 8.9). All of this is standard and well-tested.

What SCCs cannot do post-Schrems-II is guarantee that a US authority will not compel disclosure through the CLOUD Act or a §2703(d) order. The CJEU's Schrems II decision (July 2020) held that SCCs alone are insufficient where the recipient country's law does not provide "essentially equivalent" protection to GDPR. The EDPB's 2021 supplementary-measures guidance made clear that transfers to CLOUD-Act-reachable providers require additional technical measures (typically end-to-end encryption where the operator has no key access) — which for a managed BaaS like Supabase is not achievable end-to-end.

Sub-processor list under the Supabase DPA

Article 28 requires the processor to disclose sub-processors, obtain the controller's authorisation, and provide notice of changes so the controller can object. The Supabase sub-processor list is public — the main entries relevant to a compliance review are Amazon Web Services, Inc. (US) for compute, storage, and database hosting; Vercel Inc. (US) for the dashboard and marketing site; GitHub, Inc. (US, Microsoft subsidiary) for code hosting and CI/CD; Stripe, Inc. (US) for payment processing; plus a rotating list of communications and analytics providers, most US-headquartered.

For an EU controller, every sub-processor is another entry in your Article 30 RoPA and another transfer that needs its own basis. If your legal team objects to any of the above on jurisdictional grounds, your options under the DPA are: object during the 30-day notice window (Supabase may or may not accommodate) or terminate the service. There is no "select only EU sub-processors" toggle.

Eurobase's sub-processor list is fully EU-headquartered: Scaleway SAS (France) for hosting, database, storage, and edge functions; GatewayAPI (Denmark) for SMS; Mollie B.V. (Netherlands) for paid billing when it switches on. The list is auto-generated from a live database table (sub_processors) and exposed as a downloadable Article 30 RoPA report in every project.

  • ▸Sub-processors under EU jurisdiction — Supabase: partial (AWS, Vercel, GitHub, Stripe are US). Eurobase: 100%.
  • ▸Sub-processor change notice window — Supabase: 30 days. Eurobase: 30 days.
  • ▸Article 30 RoPA report — Supabase: you maintain it manually. Eurobase: auto-generated per project from the live registry.

Article 28 (processor) vs Article 30 (RoPA) — two different obligations

The DPA satisfies Article 28. It does not satisfy Article 30. Both apply, and they are frequently conflated in compliance-page marketing copy — including sometimes on our own pages.

Article 28 is the processor contract — the DPA. Signed once, updated when material terms change. Both Supabase and Eurobase provide it.

Article 30 is the Record of Processing Activities you maintain. It lists purposes, categories of data, sub-processors with transfer basis, retention periods. It updates whenever your sub-processor set or processing purposes change. Supabase gives you the raw ingredients; you assemble the record. Eurobase generates the report automatically from a live sub-processors table in every project's Compliance tab.

A "DPA report" is an ambiguous term — sometimes it means "give me the signed DPA PDF", sometimes it means "give me the Article 30 RoPA for our deployment". Our own product surfaces have historically named these inconsistently; we corrected the DSAR & Compliance card copy in September 2026 to clarify that the auto-generated report is a RoPA (Article 30), not a DPA (Article 28).

When the Supabase DPA is enough, and when it is not

Ranking based on regulated-industry procurement patterns we have seen over 2024–2026:

  • ▸Consumer SaaS, US-first, EU users welcome — Supabase DPA + SCCs + EU region is typically enough. Ship it.
  • ▸B2B SaaS selling to European SMBs, no regulated data — same as above, usually.
  • ▸Health/legal/fintech/defence/gov-tech — the DPO usually flags "EU parent" as a hard requirement, and no DPA closes the CLOUD Act vector. Eurobase or an EU-parent alternative is the honest recommendation.
  • ▸German legal-tech (Kanzlei, RA-Micro adjacent) — §203 StGB, §43e BRAO, §257 HGB, §147 AO all layer sectoral requirements that go beyond GDPR. Eurobase Legal Team tier is in closed beta specifically for this segment.

Feature comparison

FeatureEurobaseSupabase
DPA availableYes — on request from dpo@eurobase.app (self-service copy at /dpa planned for GA)Yes — dashboard (paid), on request otherwise
Counter-signature for standard termsNot required for standard termsClick-to-accept in dashboard
Standard Contractual ClausesNot required (intra-EU transfer)Required — SCCs Module 2, DPF where applicable
Sub-processor jurisdiction100% EU (FR / DK / NL)Mixed — AWS/Vercel/GitHub/Stripe are US
Sub-processor change notice window30 days30 days
Auto-generated Article 30 RoPA reportYes — per project, downloadable JSON + PDFNo — you maintain manually
DSAR (Art. 15/20) mechanism in DPAReferenced + one-click in-product exportReferenced — mechanism you build
Data-return / deletion at contract end30-day export window, 90-day backup purge90-day access, then deletion
Breach notificationWithout undue delay, ≤72h to controllerWithout undue delay
CLOUD Act reach through processorNoneYes — Delaware parent + US sub-processors

A DPA is a contract. A statute is a statute.

  • ▸Supabase Inc. publishes a solid Article 28 DPA. So does every other reputable US processor. Where their DPA cannot help you is in the jurisdiction they operate under.
  • ▸The CLOUD Act (2018) and FISA §702 bind the operator regardless of contract terms. The Microsoft France Senate testimony (June 2025) made this explicit and public.
  • ▸Eurobase's DPA is signed under Estonian law, executed by Eurobase OÜ (registry 17557586), against sub-processors that are all EU-headquartered. No US hop, no CLOUD Act reach.
  • ▸DPA + Article 30 RoPA + Article 15/20 DSAR are all first-class product surfaces, not paid add-ons.

Related reading

Supabase vs Eurobase — FAQ

Does Supabase have a DPA?

Yes. Supabase Inc. publishes a GDPR Data Processing Addendum with Standard Contractual Clauses. It is accessible from the dashboard for paid plans and on request otherwise. It is a click-to-accept contract for standard terms; Enterprise-tier customers negotiate custom modifications.

How do I get the Supabase DPA signed?

On a paid plan, open the Supabase dashboard → Organization Settings → Data Processing Agreement, review the terms, and click accept. The dashboard records the accepting user and the acceptance timestamp for audit. For Free-tier or pre-signup review, request a copy from privacy@supabase.io.

Does the Supabase DPA include Standard Contractual Clauses?

Yes. Because Supabase Inc. is a US entity, personal data flows to a non-adequate country under GDPR Chapter V. The DPA incorporates the EU Commission's 2021 Standard Contractual Clauses (Module 2: controller to processor) as the transfer mechanism, with the EU-US Data Privacy Framework used where the processor is DPF-certified. Since Schrems II (2020), SCCs alone are not sufficient where the recipient country's law permits compelled disclosure — supplementary measures may be required for high-sensitivity data.

Is a Supabase DPA enough for GDPR compliance?

For most SaaS deployments, yes — the DPA + SCCs + EU-region hosting closes the standard compliance ticket. For regulated deployments (healthcare, legal, fintech, defence, gov-tech), the DPO typically flags the CLOUD Act as an unclosed vector, because a DPA is a contract and the CLOUD Act is a statute — statutes override. In that case an EU-parent processor like Eurobase is the practical answer.

Which sub-processors does Supabase list in its DPA?

The Supabase sub-processor list includes Amazon Web Services (US) for infrastructure, Vercel (US) for dashboard, GitHub (US, Microsoft) for code hosting, Stripe (US) for payments, and a rotating list of communications and analytics providers, most of which are US-headquartered. Under Article 30 each of these adds a transfer-mechanism entry to your RoPA.

What DPA does Eurobase provide?

Eurobase's DPA is signed by Eurobase OÜ (Estonian registry code 17557586, Ahtri 12, Tallinn) as processor, available on request from dpo@eurobase.app; a self-service copy at /dpa is planned for general availability. Because operations stay intra-EU (Estonian operator with EU-headquartered sub-processors in France, Denmark, and the Netherlands), no SCCs or DPF are required. The full sub-processor list (Scaleway/FR, GatewayAPI/DK, Mollie/NL) is auto-exposed as a downloadable Article 30 RoPA report in every project's Compliance tab.

Related reading

A DPA that does not need a CLOUD Act footnote

Eurobase's DPA is signed under Estonian law, executed against 100% EU-headquartered sub-processors. Postgres, auth, storage, realtime, edge functions — all EU-native. Free tier, no credit card. Pro is €25/mo per project.