An EU Region Is Not an EU Provider — Vercel, Supabase and the GDPR Third-Country Question

Published Sep 9, 2026
by

“We host in Frankfurt, so we’re GDPR-compliant.” The sentence comes up in almost every conversation about Vercel and Supabase, and it is half the answer to a question that has two halves. The region answers where the data lives. It does not answer whose law applies to the companies that process that data.

This article takes the second half apart. It explains what an EU region delivers legally and what it does not, why the European Commission has twice declared transfers to the United States permissible by decision and the Court of Justice of the European Union has struck down both decisions while the third is under review right now, and what the CLOUD Act, a US law from 2018, has to do with a data center in Frankfurt. At the end there is a checklist for the third-country question that lets you examine and document your own use of Vercel or Supabase, plus a decision aid for the alternative. The occasion is a concrete one: In the DI² project this question was asked before the first deploy, and the answer shaped the infrastructure.

The essentials up front:

  • Not compliant by default: Vercel and Supabase offer EU regions and a data processing agreement, the contract that lays down what the provider may do with its customers’ data. The conditions for a compliant deployment still have to be established and documented by the user. The default setting is not the compliant one, and at Vercel functions run in the United States unless you choose otherwise.
  • The chain counts, not the seat: Vercel is a US company. Supabase’s contracting party sits in Singapore, the US company Supabase, Inc. appears as a subcontractor for support in its own list, and hosting runs on Amazon Web Services (AWS). Whose law applies is not stated by the provider’s legal notice but by its list of subcontractors that touch the data. The GDPR calls them sub-processors, and the providers publish them as a “Subprocessor List”.
  • Three attempts at a transfer mechanism: The European Commission has three times found by decision that the United States offers an adequate level of protection, each time on the basis of an arrangement with the US government. The first two, Safe Harbor of 2000 and Privacy Shield of 2016, were struck down by the Court of Justice in 2015 and 2020, both times for the same reason. Against the third, the Data Privacy Framework of 2023, the General Court of the European Union dismissed the first action in September 2025, and the appeal is pending before the Court of Justice. As of 9 September 2026 it stands.
  • The CLOUD Act does not ask where the data is stored: A provider under US jurisdiction must in principle hand over data in its possession or under its control, no matter which country it is stored in. There is no agreement with the EU that would open the law’s special objection procedure. Microsoft France confirmed as much before the French Senate in June 2025.
  • A contract does not cure that: The data processing agreement governs the relationship between user and provider. It does not override a US law. Both risks land on the user in the end, because the user is responsible for the processing, even though the provider has obligations of its own. The checklist at the end makes them visible instead of removing them.
  • The alternative is a provider question: Anyone who wants to rule the two risks out rather than carry them has only one route, no provider under US jurisdiction in the chain. That means an EU provider or a server of your own in the EU, and both come at a price that the sibling article on infrastructure puts into numbers.

Prerequisite: The article is aimed at developers and small teams in the EU who run a web application with a login on Vercel, Supabase or comparable services, or plan to. No legal background is required, and terms such as adequacy decision, standard contractual clauses and data processing agreement are explained where they first appear. All provider statements are taken from the providers’ own documentation, quotations verbatim, retrieved on 9 September 2026. The article is not legal advice, and it does not replace an assessment of your own case.

Contents

The Short Answer: Not by Default

Can you use Vercel and Supabase in a GDPR-compliant way? Yes, but not by creating an account and picking Frankfurt as the region. Both providers say so themselves, just not on the landing page. Vercel writes in its compliance documentation that it supports its customers’ GDPR compliance and lists five commitments to that end, from the security level to the standard contractual clauses. Supabase writes that it supports GDPR-compliant deployments. In both cases the subject of the sentence is the customer. The provider supplies the tools, and the user has to apply them, document them and answer for them.

What that involves fits in one paragraph. The user signs the data processing agreement, which the GDPR calls a contract under Article 28 and practice usually calls a DPA. The user chooses the region instead of accepting the default. The user documents the basis on which data may leave the territory of the EU, because with both providers it can do so even with an EU region, at Vercel by the provider’s own reservation, at Supabase through support and subcontractors. The user extends the privacy policy to name the recipient, the third country and the basis. And the user consciously decides whether to carry two risks that no contract takes away. Those two risks are the core of this article. The rest is the groundwork needed to understand them.

What an EU Region Delivers — and Who Is in the Chain

An EU region is a promise about storage location. At Supabase that means: Whoever creates a project in an AWS region gets the database, the auth service and storage hosted in that region, as the security page states. At Vercel the region is a choice for the part of the application that computes on the server, the so-called serverless functions, and the default is not Europe. The compliance documentation says it in one sentence: “The default location for Vercel functions is the U.S.” In front of those functions sits Vercel’s worldwide delivery network, a CDN (content delivery network), which accepts visitors’ requests at the nearest of twenty locations and serves the pages from there. The chosen region applies to the functions, not to that network.

The question of whether a service can be used in a GDPR-compliant way has two parts. The first is: Where does the data live? The region answers it, and for Supabase and Vercel alike that part is settled. The second is: Which companies process the data, and whose law are those companies subject to? No region answers that. The answer lies in the list of subcontractors the provider brings in to run the service and who touch the data in the process. Both providers publish that list, and at both it reads differently from what the marketing suggests.

Vercel: Vercel, Inc. is a US company. It is certified under the EU-US Data Privacy Framework, and it additionally relies on standard contractual clauses for transfers. Both statements are in the compliance documentation. Directly below them stands the reservation that puts the region into perspective: “Vercel may transfer data to and in the United States and anywhere else in the world where Vercel or its service providers maintain data processing operations.” Vercel may therefore move data to the United States and to any other location where it or its service providers process data. Backups, according to the same page, are replicated globally and are not accessible to customers.

Supabase: Here the research for this article produced a different picture from the expected one. According to the terms of service and the data processing agreement, the contracting party is not a US company but Supabase Pte. Ltd., based in Singapore. The terms place the contract under California law, and the data processing agreement relies on standard contractual clauses for transfers, a contract text prescribed by the European Commission in which the recipient commits to European data protection rules, and does not mention the Data Privacy Framework. Supabase’s own subprocessor list, in the version dated 1 June 2026 and retrieved on 9 September 2026, then names the companies that actually touch the data: Amazon Web Services for hosting, Cloudflare, Google and Fly.io for further hosting services, Vercel for hosting, and at the top of the list Supabase, Inc. for support. Supabase’s privacy policy names the United States and Singapore as transfer destinations, each on the basis of standard contractual clauses, and describes its own services as “primarily hosted in and provided from the United States”. The contracting party sits in Singapore, the data sits with a US host, and the US company has access as a subcontractor.

For the GDPR the seat in Singapore changes nothing about the classification. An adequacy decision is the European Commission’s finding that a country outside the EU protects personal data as well as the EU itself does. Where one exists, data may go there as if it stayed in the EU. For Singapore no such decision existed at the time of writing, and for the United States it applies only to companies with an active certification under the Data Privacy Framework, and only to the data types that certification covers. Every transfer to Singapore is therefore a third-country transfer that needs a mechanism of its own, in Supabase’s case the standard contractual clauses. What the case shows is something else: The provider’s legal notice is the wrong place to answer the provider question. The right place is the list of subcontractors. As soon as a service provider under US jurisdiction appears there that processes personal data or can access it, and with services on AWS, Google Cloud or Azure one regularly does, two things have to be examined separately for that data. First, whether a third-country transfer takes place and on what basis, which is the next section. Second, what state access risk that link brings with it, which is the section after that. How large the second risk actually is depends on which data the link really has in its possession or under its control. The EU region has settled the storage location. The chain has settled which legal systems have a say.

Three things come on top with every region, because they do not hang on the storage location. Support access, which the provider needs to operate the service, happens from wherever its staff sit. Metadata, meaning account data, invoices and access logs, runs in the provider’s systems and not in the chosen region. And backups sit wherever the provider replicates them, at Vercel explicitly worldwide.

The Transfer Mechanism: Three Attempts

The first of the two risks concerns the basis on which data may leave the EU at all. The GDPR allows transfers to a country outside the EU only under the conditions of its Chapter V. The yardstick behind it is that the data keeps a level of protection there that is essentially equivalent to the European one, and there are three routes to that. The first is an adequacy decision by the European Commission under Article 45, with which the Commission finds across the board that a country offers that level. The second is appropriate safeguards under Article 46, in practice almost always the Commission’s standard contractual clauses, with which the recipient contractually commits to European rules, more rarely binding corporate rules within a group of companies. The third is a set of narrowly drawn exceptions under Article 49, such as explicit consent for a single transfer, which are no use for a running service.

For the United States the Commission has taken the first route three times, and twice the Court of Justice has struck the decision down.

Safe Harbor, the 2000 decision: US companies could self-certify that they observed certain principles. After the revelations about US surveillance programs in 2013, Max Schrems, then a law student in Vienna, lodged a complaint against Facebook with the Irish data protection authority because his data was going to the United States. The complaint reached the Court of Justice via the Irish High Court, and the Court declared the decision invalid on 6 October 2015. The reasoning was that US authorities had general access to the content of communications and EU citizens had no legal remedy against it.

Privacy Shield, the 2016 decision: The successor came with an ombudsperson in the US State Department and further commitments. Again it was a complaint by Schrems, who by then was running data protection cases full time with the organization noyb, and both judgments therefore carry his name, Schrems I and Schrems II. The Court of Justice struck the decision down on 16 July 2020, on the same grounds in updated form. The surveillance powers under Section 702 of the Foreign Intelligence Surveillance Act (FISA), the US law on foreign intelligence, and Executive Order 12333, a presidential order issued without Congress, were not limited to what is necessary, EU citizens could not challenge them before any US court, and the ombudsperson was neither independent nor able to bind the intelligence services. In the same judgment the Court made clear that the standard contractual clauses remain valid, but that whoever exports data must assess for the specific transfer whether the law and practice of the receiving country guarantee the level of protection, and must provide additional measures where needed. That assessment is usually called a transfer impact assessment, and it applies then as now. Between 2020 and 2023 it affected almost every transfer to the United States, and since the third attempt only those that do not rely on it, as in the Supabase case.

Data Privacy Framework, the 2023 decision: The third attempt rests on an executive order of the US President from October 2022 that lays down proportionality principles for the intelligence services and sets up a review court, the Data Protection Review Court, before which EU citizens can bring complaints against surveillance measures. On that basis the Commission adopted the adequacy decision on 10 July 2023. US companies self-certify again, and the US Department of Commerce keeps the list. Vercel says it is on it. Supabase does not mention the framework in its contract, its security page or its privacy policy and relies on standard contractual clauses.

The decision is under attack. The French member of parliament Philippe Latombe challenged it directly before the General Court of the European Union, and the General Court dismissed the action on 3 September 2025. It found that the United States ensured an adequate level of protection at the time of the decision, and it expressly tied that finding to that point in time. On 31 October 2025 Latombe lodged an appeal with the Court of Justice, case number C-703/25 P, on four grounds. On 4 June 2026 the Court admitted Microsoft as an intervener in support of the Commission. As of 9 September 2026 no hearing date is known, and the decision stands.

Two things are worth keeping in view. First, the framework rests on an executive order, not on a statute, and an executive order can be changed by the next president. Second, the US oversight body that is supposed to monitor compliance with the commitments, the Privacy and Civil Liberties Oversight Board, has been without a quorum since three of its members were dismissed in January 2025. Its own members page lists a single serving member on 9 September 2026. The dismissals are themselves the subject of litigation: A federal court in Washington declared them unlawful in May 2025, and the appeals court stayed that ruling in July 2025 for the duration of the proceedings. Whether and how that enters the judicial review of the framework is open. For the user both mean that the basis of their transfer depends on political decisions in another country.

If this decision is struck down too, what happened in 2020 happens again. Whoever relied on the framework alone is left without a basis and has to switch to standard contractual clauses, including their own assessment of US law. Whoever documented both from the start, the provider’s list entry and the standard contractual clauses in the data processing agreement together with the assessment of US law, has less to do on that day. That is exactly why the checklist below carries them as two separate items.

The CLOUD Act: Possession or Control, Not Storage Location

The second risk, the CLOUD Act, is independent of the first, and it survives every adequacy decision. Its origin is a dispute over emails. In 2013 US investigators demanded from Microsoft, by warrant, a mailbox that sat in a data center in Dublin. Microsoft refused, arguing that a US warrant did not reach as far as Ireland. An appeals court sided with Microsoft in 2016, the Supreme Court took the case, and before it could decide, Congress passed a law that answered the question. The Clarifying Lawful Overseas Use of Data Act, CLOUD Act for short, was signed on 23 March 2018.

The core rule is in 18 U.S.C. § 2713. A provider must in principle hand over content and subscriber records that are “within such provider’s possession, custody, or control”, and that “regardless of whether such communication, record, or other information is located within or outside of the United States”. In one sentence: What counts is whether the provider possesses or controls the data, not where it is stored. A data center in Frankfurt is no argument against this rule.

The law provides a special objection procedure for the case that disclosure would violate the law of another state, but only under two conditions at once. The customer concerned must not be a US person, meaning neither a US citizen nor resident in the United States, and the United States must have concluded an agreement under this law with the country where the data is stored. Such agreements exist so far with the United Kingdom, in force since October 2022, and with Australia, in force since January 2024. With the EU or any of its member states there is none. For data in Frankfurt the second condition is missing, and with it this route. What remains is the general possibility of challenging a demand as unlawful, as Microsoft did in the Ireland case. That presupposes a provider that does so.

On the European side stands Article 48 of the GDPR. It recognizes decisions by authorities of a third country only if they rest on an international agreement, such as a mutual legal assistance treaty in which states promise each other support in investigations. A US provider with EU customers thus stands between two legal systems that demand opposite things. The data processing agreement with the customer does not resolve that conflict, because a contract between two companies does not override a US law. What the contract can deliver is a commitment to inform the customer and to contest demands for disclosure as far as the law allows.

What that sounds like in practice was shown by Microsoft France before a committee of inquiry of the French Senate in June 2025. Anton Carniaux, in charge of legal and public affairs there, was asked whether he could guarantee that data of French citizens would never be handed to US authorities without France’s consent. His answer is in the minutes of the session of 10 June 2025: “Non, je ne peux pas le garantir, mais, encore une fois, cela ne s’est encore jamais produit.” No, he could not guarantee it, but it had never happened so far either. And on the question of the obligation: “Lorsque nous sommes obligés de les donner, nous les donnons.” When Microsoft is obliged to hand data over, it hands it over. The two sentences belong together. The first names the risk and how often it has materialized so far, the second the rule behind it: disclosure after the provider’s own check of whether the demand is lawful, not before. That is not a statement about other providers, but it is one about the limit of what any provider can promise.

That leads to proportionality. The probability that US authorities take an interest in the user table of an ETL tool with a handful of users is low. The risk is structural, not practical. It consists in the user writing a promise into their privacy policy that they cannot keep, because their provider cannot keep it. Whoever understands that and accepts it consciously acts differently from someone who does not know it. That difference is what the last item of the checklist is about.

A question that comes up regularly here concerns the European subsidiaries of US groups. If the contracting party is called AWS Europe in Luxembourg or Microsoft Ireland, does that help? The seat of the contracting party alone does not answer the question. The rule turns on possession, custody or control, and whether a company within a group controls the data in that sense is a matter of actual access, not of the org chart. The Microsoft Ireland case was the trigger for the law because it concerned data held by a European subsidiary, but no blanket rule follows from it that every EU subsidiary automatically holds data under the control of its US parent. What does follow is the duty to check which company actually gets to the data. That is exactly what makes the Supabase case above so instructive. There it is the other way around: The contracting party sits outside the United States, and the US company is in the chain regardless, with support access.

The Checklist

What a user has to examine and record for the third-country question at Vercel, Supabase or a comparable service can be worked through in seven items. The list does not create compliance and does not replace an assessment of the processing as a whole. It does not remove the two risks, it makes them visible and documents the decision to carry them. For an operator who gets asked, that is the difference between an answer and a shrug.

  1. Read the subprocessor list: Mark every company subject to US jurisdiction (host, parent company, support), and record for each link which data it processes or can view. Only for that data does the CLOUD Act question arise.
  2. Sign the data processing agreement: Conclude the contract under Art. 28 GDPR (DPA) and file it. Check whether it contains standard contractual clauses.
  3. Choose the region: Do not accept the default. At Vercel set the function region, at Supabase the project region. Record what the region covers and what it does not (CDN, backups, support, metadata).
  4. Document the transfer mechanism, both separately: The provider’s active entry under the Data Privacy Framework (look it up yourself on dataprivacyframework.gov, including its scope) and the standard contractual clauses from the contract together with your own assessment of US law (transfer impact assessment). If the framework is struck down, the second basis carries on, but only with that assessment.
  5. Extend the privacy policy: Recipient with company name and seat, third country, transfer mechanism, and a note on possible government access under the law of the third country.
  6. Subscribe to changes of the subprocessor list: Both providers announce changes, and the list changes several times a year.
  7. Decide the residual risk consciously and record it with a date: Which data sits with the provider, how serious would access be, and why is the operator prepared to carry that.

The provider information in this article is current as of 9 September 2026. The lists change, and what counts is always the current version at the provider. Item 1 comes first because it determines the others. Whoever reads the list knows for whom to document item 4 and what to write in item 5. Item 7 is the one most people leave out. It is the only one that demands a decision rather than a document, and it records the actual risk decision that stands behind the other six items.

The Alternative: EU Provider or Self-Hosting

Anyone who wants to rule the two risks out rather than carry them has only one route, no provider under US jurisdiction in the chain. Anyone who can carry them has the checklist. In practice the one route means either an EU provider that runs its own data center, or a server of your own with such a provider.

What an EU provider solves: With a provider based in the EU, with its own infrastructure and with no third-country subcontractors in the chain, examples for the first two conditions being Hetzner in Germany, IONOS in Germany and OVHcloud in France, without rating the products, the third-country transfer can drop away for the infrastructure layer, provided support access and the remaining data flows also stay in the EU. Then there is no adequacy decision to check, no standard contractual clauses for the host and no CLOUD Act for the data center. The data processing agreement remains mandatory, and so does the look at the subprocessor list, because an EU provider can use US service providers. Reading the list is item 1 here too.

What self-hosting costs: The price is not primarily money but operations. Whoever runs an application with a login on their own server takes on the reverse proxy, which passes requests from the internet on to the application, the certificates, the identity provider, which manages login and users, the database, the backups and the monthly updates across every layer. In the DI² project that was the decision, and the sibling article One VPS, Four Environments, No Cookie Banner describes what it cost, from the RAM budget through secrets in two places to the monthly bill. On your own server in the EU the third-country question does not arise for the infrastructure. That is the real difference between the two routes, not the price.

Decision aid: Three questions suffice for most cases. First, which data sits with the provider, only account data or also what users enter into the application? The closer to health, financial or employee data, the heavier item 7 of the checklist weighs. Second, who will ask, a customer with a data protection department of their own, a supervisory authority, nobody? Whoever has business customers in the EU will get the question. Third, who carries operations, and what happens when that person is out for two weeks? A managed service answers the third question better than a server of your own, and that is a legitimate reason for Vercel or Supabase. It should just be taken together with the answers to the first two questions and written down.

Summary

  • An EU region answers where the data lives. It does not answer whose law applies to the companies that process it. That answer is in the subprocessor list.
  • Vercel is a US company with a certification under the Data Privacy Framework, a US default for functions and an explicit reservation to transfer data to the United States and to any other processing location. Supabase’s contracting party sits in Singapore, the US company Supabase, Inc. is a subcontractor, and hosting sits with AWS. In both chains there are companies under US jurisdiction.
  • The transfer mechanism for the United States, a decision of the European Commission, has been struck down twice by the Court of Justice, and the third is under review right now. As of 9 September 2026 the Data Privacy Framework stands, and appeal C-703/25 P is pending. Whoever documents the list entry and the standard contractual clauses separately has less to do on the day of a judgment.
  • The CLOUD Act in principle obliges providers under US jurisdiction to hand over data in their possession or under their control, regardless of storage location. The law’s special objection procedure presupposes an agreement that does not exist with the EU. A data processing agreement changes none of that.
  • The checklist makes both risks visible and documents the decision to carry them. It does not remove them. Whoever does not want to carry them needs an EU provider or a server of their own in the EU, and both cost operations rather than money.

FAQ

Is Vercel or Supabase GDPR-compliant if I pick the Frankfurt region?

Not by default, the region only settles the storage location. At Vercel the documented reservation remains, to transfer data to the United States and to any other processing location, and at Supabase the US companies remain in the subprocessor list, above all the host AWS and Supabase, Inc. for support. Both are third-country transfers that need a mechanism, a data processing agreement and a note in the privacy policy. The region is item 3 of the checklist, not the checklist.

Is the Data Privacy Framework still valid in September 2026?

Yes. The European Commission’s adequacy decision of 10 July 2023 stands, and the General Court of the European Union dismissed the first action against it on 3 September 2025. Appeal C-703/25 P has been pending before the Court of Justice since 31 October 2025, Microsoft has been admitted as an intervener in support of the Commission since 4 June 2026, and as of 9 September 2026 no hearing date is known. To check the current state, search for the case number on curia.europa.eu.

What happens if the Court of Justice strikes down the Data Privacy Framework too?

The same as in July 2020 with Privacy Shield. Transfers that rest on the framework alone lose their basis from one day to the next. Whoever has additionally agreed standard contractual clauses in the data processing agreement relies on them from that day on and has to carry out the assessment of US law themselves, as every company did between 2020 and 2023. That is why the checklist documents both mechanisms separately.

Does the CLOUD Act apply to AWS, Azure or Google Cloud data in Germany?

Storage in Germany changes nothing if the provider is subject to US jurisdiction. The rule turns on possession, custody or control, so the question is which company within the group actually gets to the data. A contracting party based in Luxembourg or Dublin does not answer that by itself, but a US parent in the org chart does not automatically answer it the other way either. Whether and how a group contests a disclosure in a given case is a matter of its contract and its practice, not of the subsidiary’s seat.

Do I need to care about this for a hobby project with five users?

The obligations apply regardless of size as soon as personal data is processed, and a login table with email addresses is enough for that. The risk of government access is structural, not practical, with five users. What remains is the duty not to promise anything in the privacy policy that the provider cannot keep. The checklist takes an afternoon for a small project, and item 7 is then an honest line instead of an empty promise.

Sibling article:

Hub of this branch:

Cluster hub: