Supabase data residency and sovereignty

Where every byte you put into Supabase actually lives, surface by surface, and which of the three sovereignty questions a given deployment model can answer. The audience is anyone who has to write “where is our data?” into a contract, a data protection impact assessment (DPIA), or an architecture review.

Provenance. The region catalogue, smart-region behavior, edge routing, and Edge Function placement were measured against the live platform on 2026-08-10 (Management API calls plus HTTP response headers, from Singapore, against a project in eu-central-1), and re-measured on 2026-08-20 against a project in eu-central-2 (Zurich), when the Storage CDN cache matrix and the Realtime partitioning claims were also measured. Everything else is documented behavior with a citation at the claim; the evidence table at the end splits measured from documented. Where the docs are silent - the backup storage region, the log store region, the branch region, the control plane’s hosting location - this doc says so rather than guessing.

TL;DR:

A project region pins Postgres, the Auth service, and Storage objects. That is the whole guarantee.¹ Backups, logs, Edge Function execution, read replicas, and subprocessors sit outside it.¹
There are 17 specific regions and 3 smart groups (measured via the Management API). Smart groups are capacity-driven: “Europe” can land in London or Zurich, which are not EU member states.² Smart group codes are rejected in the region field of the public project-creation API (measured); the documented place for one is the region_selection object.³ There is no Middle East region, and no Jakarta or Kuala Lumpur.
Every API request transits the Cloudflare edge nearest the user (measured: a Singapore client hits the SIN PoP for an eu-central-1 project) regardless of project region.
Realtime is a global cluster.⁴ Edge Functions execute closest to the user by default (measured: ap-southeast-1 for a Singapore caller against a Frankfurt project) and are pinnable per-invocation.⁵
Logs leave the project by design - extracted to systems segregated from customer projects.⁶ The log store’s region is not documented. Log Drains (Pro and up) export to an endpoint you control.⁷
The contracting entity is Supabase Pte. Ltd (Singapore); the DPA incorporates EU Standard Contractual Clauses (SCCs) under Irish law.⁶ The subprocessor list puts Supabase, Inc. (US) in for support, plus AWS, Cloudflare, Google, Fly.io, Vercel, and Upstash.⁸
SOC 2 Type 2 and ISO 27001 reports are available to Team and Enterprise; HIPAA needs a Business Associate Agreement (BAA) (Team plan minimum) plus the add-on and a High Compliance project configuration.⁹¹⁰
Residency is achievable on managed Supabase, surface by surface. For the other two layers the doc gives you the inputs rather than a verdict: the subprocessor list names US-incorporated entities in every managed deployment (Supabase, Inc. for support; AWS, Cloudflare, Google, Vercel for hosting)⁸, and 18 U.S.C. Section 2713 reaches data in a covered provider’s “possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.”¹¹ Whether that combination binds a given deployment is a question for counsel, not for this doc.

Three different questions

Buyers say “data residency” and mean any of three stacked requirements. They have different answers, and confusing them is how a residency project ends up with the wrong deployment model.

Layer	The question	What answers it
Residency	Where do the bytes physically sit?	Region selection, plus discipline about replicas, functions, and logs
Vendor sovereignty	Can Supabase (the vendor) read or move the data?	Nothing on managed removes the control plane and support paths; self-hosting does
Jurisdictional sovereignty	Can a foreign state compel the data, regardless of where it sits?	An operator outside that state’s jurisdiction - not a region choice

The rest of this doc is organised by the first question, because it is the one with a per-surface answer. The other two get their own sections at the end.

What the project region pins

Each project is deployed to one primary region, chosen at creation, and bound there at the infrastructure level - there is no in-place region change.²¹² Moving means a new project and a migration; the region migration guide walks that path end to end.

The pin covers three things: your primary Postgres database, the Auth service, and Storage objects.¹ Supabase’s own GDPR page is explicit about what the pin does not cover: “Backups, logs, data exported to external systems, Edge Function execution, and sub-processors can affect your data residency and international transfer analysis.”¹

The region catalogue, measured

GET /v1/projects/available-regions?organization_slug=<your org> returned the following on 2026-08-10 (re-measured 2026-08-20).³ Two sharp edges: the organization slug is mandatory - a bare call answers 400 - and the response shape is { recommendations, all: { smartGroup, specific } }, where recommendations is the platform’s capacity pick for your org (a Singapore vantage was recommended americas / us-west-2). That block is the platform’s capacity pick made visible - read it before choosing a smart group; whether a smart-group create lands on the recommended region was not measured (residency-facts R01, 2026-08-20).

Area	Specific regions
North America	`us-west-1`, `us-west-2`, `us-east-1`, `us-east-2`, `ca-central-1`
Europe	`eu-west-1` (Ireland), `eu-west-2` (London), `eu-west-3` (Paris), `eu-central-1` (Frankfurt), `eu-central-2` (Zurich), `eu-north-1` (Stockholm)
Asia Pacific	`ap-south-1` (Mumbai), `ap-southeast-1` (Singapore), `ap-southeast-2` (Sydney), `ap-northeast-1` (Tokyo), `ap-northeast-2` (Seoul)
South America	`sa-east-1` (Sao Paulo)

Plus three smart groups: americas, emea (displayed as “Europe”), apac.

Three consequences:

Smart groups are a capacity control, not a jurisdiction control. A smart group deploys to an available AWS region inside the area, and “Europe” includes London and Zurich - adequate under GDPR, but not EU member states. If the requirement is EU-soil-only, pick a specific region.²¹
A smart group is not a value for the region field. POST /v1/projects with "region": "emea" returns 400 {"message":"region: Need to use one of available regions."} (measured 2026-08-10, re-confirmed 2026-08-20). The documented shape for a smart group on that endpoint is the sibling region_selection object - {"type": "smartGroup", "code": "americas"} - and GET /v1/projects/available-regions is documented as the way to read the codes.³ region_selection works on a normal paid org, so it is not a Supabase-for-Platforms gate: {"type": "smartGroup", "code": "apac"} on a Pro org returned 201, landed ap-northeast-2 and was healthy in 135s (instance-sizing I02, 2026-08-17). Programmatic per-customer placement therefore either enumerates specific regions or switches to region_selection; use the latter only when capacity matters more than the soil, and pass a specific region otherwise.
The map has holes that decide deals. No Middle East region at all, though AWS itself operates two (me-central-1 UAE, me-south-1 Bahrain), and neither of AWS’s Jakarta (ap-southeast-3, Indonesia) nor Malaysia (ap-southeast-5) regions¹³ - all measured absences from the region catalogue above. Pasal 20(2) of Indonesia’s PP 71/2019 requires public-scope electronic system operators to manage, process and/or store their electronic systems and data in Indonesian territory; 20(3) permits doing so abroad where the storage technology is unavailable domestically, on criteria a government committee sets under 20(4).¹⁴ Managed Supabase offers no Indonesian region, so an operator inside 20(2) would be relying on the 20(3) exception. Whether an equivalent in-country mandate applies to Middle East or Malaysian buyers is not something this doc checked.

The per-surface map

Every surface, what it holds, where it lives, and what control you have. “Follows the project” means the surface runs in or against the project region. Details and citations follow in the per-surface sections.

Surface	What it holds	Where it lives	Region control
Postgres	Your tables, including the `auth` schema	Project region	Fixed at creation; immutable in place
Vault secrets	Encrypted secrets in Postgres	Ciphertext follows Postgres; the root key lives in Supabase backend systems, region not documented	Follows Postgres
Cron, Queues, pg_net	Jobs, queue messages	Inside Postgres	Follows Postgres
Daily backups / PITR	Snapshots and WAL archives	S3, “a storage system independent of the Customer’s project resources”; region not documented	None documented
Read replicas	Full physical copy of Postgres	The region you pick per replica	That region is the choice
Auth service	Users, sessions, signing keys	Project region	Follows Postgres
Auth email	Message bodies, recipient addresses	Default: a Supabase-run SMTP service, provider not named; custom SMTP recommended	Your SMTP choice
Auth SMS	Phone numbers, OTPs	Your provider: Twilio, MessageBird, Vonage, or TextLocal	Your provider choice
CAPTCHA	Challenge tokens	hCaptcha or Cloudflare Turnstile	Your provider choice
Storage objects	Files	The origin storage server runs in the project region	Follows the project
Storage CDN	Cached copies of objects - public, private, and signed-URL responses alike (measured: the cache key is the object/token, not the user)	Global per-PoP cache, evictable; Smart CDN syncs object metadata to the edge	None - private buckets do not stay off the CDN, and policy revocation does not evict a cached copy
Image transformations	Resized derivatives	imgproxy; hosted execution location not documented; derivatives cached on the CDN	None documented
Realtime	CDC events, broadcast payloads, presence state	A globally distributed Elixir cluster; presence state is sent to all connected nodes; broadcast persists in `realtime.messages` (daily partitions, 3-day documented retention, measured lazy creation)	None documented
Shared pooler (Supavisor)	Connection state, credentials in transit	Per-region shared infrastructure; the hostname carries the region	Follows the project
Dedicated pooler (PgBouncer)	Connection state	Co-located with your Postgres	Follows the project
Edge Functions	Your code, request and response payloads	Default: the region closest to the user (measured), from a 15-region list	Pin per-invocation with `x-region`
Logs	API, Postgres, Auth, Storage, Realtime, function logs	Extracted to systems segregated from customer projects; ClickHouse (BigQuery for older projects); store region not documented	None documented; drain to your own endpoint (dashboard-only config, custom endpoints unsigned)
Metrics API	~200 Postgres series	Served from the project domain itself	Follows the project
Branches	Schema (no production data by default)	A separate instance per branch; region not documented	None documented
Control plane	Org, billing, project metadata, configuration	`api.supabase.com` and the dashboard; hosting location not documented	None
Support	Support-access paths into projects	Supabase, Inc. (US) per the subprocessor list; follow-the-sun staffing	None

Postgres, backups, and replicas

The database itself is the clean part: it runs in the project region, encrypted at rest (AES-256; keys protected by FIPS 140-2 hardware security modules (HSMs)), and everything that lives inside it - tables, the auth schema, Vault ciphertext, Cron jobs, Queues messages - inherits the pin.⁶¹⁵¹⁶¹⁷ One Vault caveat: the root encryption key is not stored in your database; Supabase manages it per-project in “our secured backend systems,” whose location is not documented.¹⁵

Backups are the first leak out of the region. Daily snapshots go to off-site durable storage, which the backups page describes only as “durable cloud storage, such as S3”; PITR streams WAL files (WAL-G, two-minute intervals, two-minute worst-case RPO) to off-site durable storage, and enabling PITR replaces daily backups.¹⁸ The DPA describes backups as stored “on a storage system independent of the Customer’s project resources,” encrypted in transit and at rest - but no page states which region that storage system is in.⁶ Treat backup location as undocumented, and if backups-in-region is a contractual requirement, raise it with Supabase before signing rather than assuming it. Backups also do not include Storage objects - the database only holds object metadata.¹⁸

Read replicas copy the entire database to a region you choose per replica, and that copy is a residency event: a US replica of an EU primary puts EU data on US soil.¹⁹ Requests to “Auth, Storage, and Realtime, aren’t able to use a Read Replica or its API endpoint”; you may route those services through the load balancer, but geo-routing there “aren’t yet available” and “all Auth requests are handled by the Primary, even when sent over the load balancer endpoint.”²⁰ Only Data API reads are geo-routed to a replica.²⁰ Smart-region projects cannot take replicas, and general regions are not supported for them.²

Auth

The Auth service runs in the project region and keeps its state in the auth schema of your Postgres, so the service itself follows the pin.¹ The third-party flows around it do not:

Email. The default is a Supabase-provided SMTP service, explicitly “best-effort,” rate-limited, and restricted to pre-authorised team addresses - not meant for production.²¹ The docs do not name its operator or location; Postmark appears on the subprocessor list for “communication with Authorized Users.”⁸ Set a custom SMTP provider (Resend, AWS SES, Postmark, SendGrid, and others are supported) and you pick whose infrastructure touches the message bodies and recipient addresses.²¹
SMS. Phone login goes through a provider you configure: Twilio, MessageBird, Vonage, or TextLocal.²² Numbers and OTPs transit that provider.
CAPTCHA. hCaptcha or Cloudflare Turnstile.²³

The shared responsibility model puts these on you: “You are responsible for third-party services” - OAuth and SAML providers, SMTP and SMS APIs, and any external call your functions make.²⁴

Storage and the CDN

For every object “the origin is the storage server running in the same region as your project”; the storage medium behind that server is not named in the docs.²⁵ Database backups “do not include objects you store via the Storage API,” so Storage residency is its own question rather than a corollary of the database’s.¹⁸ The leak is the cache. Every Storage asset is cached on a CDN “to improve the latency for users all around the world,” per-PoP and evictable, and Smart CDN synchronises object metadata to the edge so cache revalidation is automatic - invalidation takes up to 60 seconds to propagate globally.²⁵²⁶ Signed-URL responses are edge-cached too, keyed by token.²⁶ The cache is operated by Cloudflare - the docs never name the provider, but cf-cache-status is the documented cache header, and server: cloudflare is on every Storage response (measured).²⁵

The cache matrix, measured 2026-08-20 against a Zurich project (public bucket, private bucket, signed URLs, three users):

Public objects: first read MISS, repeat HIT. As documented.
Signed URLs: per-token keying confirmed - a repeat of the same signed URL hits, a fresh token for the same object misses. One trap: the token embeds the expiry, so two sign calls in the same second with the same expiresIn return the same URL.
Private buckets do not get per-user misses, contradicting the docs. The CDN fundamentals page says private-bucket objects are permission-checked per user, so two users in the same region both miss. Measured: user 1 MISS then HIT, and user 2’s first read was a HIT. The cache key is the object, not the user.
A cached private object survives policy revocation at that PoP. With a permissive policy both users read the object; the policy was then tightened to user 1 only. A third user who had never read it got 400 - authorisation is checked on a miss. User 2, previously authorised, got 200/HIT: on a hit, the CDN serves the bytes without re-evaluating the policy. Reproduced across three consecutive runs. The object carried Cache-Control: no-cache and was cached anyway. The exposure window is the PoP’s cache TTL/eviction, which this measurement did not bound.

Two imperatives follow directly from that matrix. Vary expiresIn when you need distinct signed URLs for the same object inside one second; the token embeds the expiry, so the wall clock alone does not change the URL (R05). And treat a policy change alone as no revocation for anything already cached: the tightened policy denied a never-authorised user on a miss and served the previously-authorised user from cache (R05c, three consecutive runs). Whether deleting or moving the object evicts the cached copy was not measured; the Smart CDN page documents about 60 seconds for invalidation to propagate, which is a documented figure, not a run.²⁶

So: Storage at rest follows the project region; Storage as served is global by default - and private buckets do not change that. A private bucket limits who can request an object; once any authorised user pulls it through a PoP, that PoP holds a copy until eviction, and later policy changes do not evict it. For regulated objects, serve them from storage you control end to end, or accept that every authorised reader’s PoP holds a copy. Image transformations (resize, optimise) run through imgproxy - “under the hood we use imgproxy” - and where the hosted transformation itself executes is not documented.²⁷ Transformed images sit behind the same cache: Smart CDN invalidation covers them.²⁶

Poolers

The Shared Pooler (Supavisor) is multi-tenant, available on every project, and IPv4-only; its connection string points at aws-[REGION].pooler.supabase.com, so the region travels with the string.²⁸ The Dedicated Pooler (PgBouncer) is provisioned for paying customers, co-located with your Postgres instance, and reached at the same db.[ref].supabase.co host as the direct connection.²⁸ Poolers hold connection state and credentials in transit rather than stored data, so the residency question is only where the pooler itself runs: for the Dedicated Pooler that is the Postgres host, and for the Shared Pooler nothing below the region tag in the hostname is documented.

Realtime

Realtime is not a regional service wearing a region’s name: it is “a globally distributed Elixir cluster,” and clients connect to any node.⁴ A client on a US node can message a client on a Singapore node; the cluster “knows the region your database is in, and connects to it from the closest region possible.”⁴ Two mechanisms from the architecture page matter for residency: Presence state “is sent to all connected Realtime nodes” - user state fans out globally by design - and Broadcast messages are persisted through a realtime.messages table, “partitioned by day,” with “partitions retained for 3 days.”⁴

The partitioning claim was measured 2026-08-20: it is real but lazy. A fresh project has the realtime.messages table with zero partitions attached, and a SQL realtime.send() there warns no partition of relation "messages" found for row and drops the message. Partitions are created by the Realtime service, not the SQL path: after one websocket client subscribes, five daily partitions appear (pre-created for +/-2 days around today), all under a supabase_realtime_messages_publication publication. The 3-day retention is not observable on a minutes-old project, so it remains doc-only. The operational consequence: subscribe at least one Realtime client before relying on SQL realtime.send() on a fresh project, or the message is dropped with the warning above (R06).

There is no documented way to pin a project’s Realtime traffic to a region. The mitigation with the tightest data path is postgres_changes only: those events flow from your Postgres WAL to the Realtime node closest to your database, without the global presence/broadcast fan-out. If a payload may not leave a jurisdiction, keep it out of Presence and Broadcast - postgres_changes or poll the Data API instead.

Edge Functions

Edge Functions default to executing “in the region closest to the user making the request” - not the region of the project.⁵ Measured from Singapore against an eu-central-1 project: the function runtime answered from ap-southeast-1 (x-sb-edge-region response header), and re-invoking with the x-region: eu-central-1 header moved execution to Frankfurt.⁵ The pinnable list is 15 AWS regions, close to but not identical with the 17-region project list - it omits us-east-2 and eu-north-1, and adds nothing.⁵

Two details that matter for residency work: pinning is per-invocation (a header or forceFunctionRegion query parameter, or the client-library region option), so it is a client discipline, not a project setting; and a pinned request is not re-routed on failure - you trade failover for placement.⁵ The gateway routes by requester IP and distributes the function bundle to edge locations globally on deploy, so your code is replicated worldwide regardless of where invocations execute.²⁹

Logs, metrics, and telemetry

Logs leave the project by design. The DPA’s technical-measures schedule states that “Logs and metrics used for observability and debugging are automatically extracted and sent to systems that are segregated from Customer projects that contain Customer’s data.”⁶ The Logs Explorer runs on ClickHouse (the default since June 2026; older projects use BigQuery).³⁰ Retention of API and database logs is set by plan - 1 day on Free, 7 on Pro, 28 on Team, 90 on Enterprise.³¹ No page states where the log store is hosted, so treat log residency as undocumented. If your analysis requires logs in-jurisdiction, Log Drains (Pro and up) stream the full stack’s logs to your own HTTP endpoint, an OpenTelemetry Protocol (OTLP) collector, Datadog, Loki, S3, and others.⁷ Two caveats on drains, both as of 2026-08-20: requests to a custom HTTP endpoint are unsigned (the log-drains page states this directly, with signed requests promised for a future release), so your endpoint cannot authenticate the sender beyond any static header you configure; and drain configuration is dashboard-only - zero drain-configuration operations exist across the entire published Management API OpenAPI document (measured by enumerating the spec, not by probing paths). A drain adds a copy you control; it does not stop the platform-side one.

API logs carry Cloudflare request metadata (metadata.request.cf.*) because every request arrives through the Cloudflare edge.³⁰ The Metrics API is the opposite shape: a Prometheus-compatible feed of about 200 Postgres performance and health series, served from the project domain itself at /customer/v1/privileged/metrics, so it follows the project region.³² For HIPAA projects, Postgres connection logging is part of the required configuration and must stay enabled.¹⁰

The edge in front of every request

Measured 2026-08-10: every response from a project’s REST and Storage endpoints carries server: cloudflare and a cf-ray PoP code, and the PoP is the one nearest the caller - SIN for a Singapore client calling an eu-central-1 project. TLS terminates there. Supabase documents the relationship obliquely - it “protects against Distributed Denial of Service (DDoS) attacks at the edge via Cloudflare,” and Cloudflare metadata appears in API logs - and Cloudflare, Inc. appears on the subprocessor list as a hosting provider.³³³⁰⁸

The project region pins where data is stored and processed at origin, but every request and response - including Authorization headers, JWTs, query parameters, and response bodies - transits a global CDN PoP chosen by the caller’s geography, not yours. For most threat models this is ordinary TLS termination at a subprocessor edge; for strict jurisdictional analyses it belongs in the transfer inventory.

Control plane, branches, and support

The control plane - api.supabase.com, the dashboard, org and project metadata, billing - is a separate SOC 2 environment from your project, and the DPA treats support requests and account contact details as Covered Data.⁹⁶ Its hosting location is not documented (Vercel and Fly.io appear as hosting subprocessors).⁸ Branches are separate instances with their own credentials and start without production data “to better protect your sensitive production data,” but the region a branch runs in is not documented.³⁴

Support is a data flow too. The subprocessor list names Supabase, Inc. - the US entity - for “provision of support services,” and the DPA describes a follow-the-sun staffing model and retained audit trails “of all interactions with Customer projects.”⁸⁶ The docs do not describe the technical support-access path into a project; what is contracted is least-privilege access, mandatory 2FA, and segregated networks between the control plane and customer projects.⁶

Compliance programs

Program	What it is	Who gets it	Residency relevance
SOC 2 Type 2	Annual audit over a rolling 12-month window (1 March - 28 February); scope covers the platform hosting Postgres, Storage, Auth, Realtime, Edge Functions, and the Data API⁹	Report downloadable by Team and Enterprise orgs from the dashboard⁹	The SOC 2 page asserts “All data will remain within the chosen region” - read it against the GDPR page’s caveats below⁹
ISO/IEC 27001:2022	ISMS certification³⁵	Certificate available to Team and Enterprise orgs from the dashboard³³	None directly
HIPAA	BAA plus the HIPAA add-on, then projects flagged High Compliance¹⁰	BAA requires at least the Team plan²⁴	High Compliance forces PITR, SSL enforcement, network restrictions, and connection logging¹⁰; Supabase signs BAAs with its own vendors that can access ePHI (AWS named), and the controls are not supported out of the box on self-hosted³⁶
GDPR	DPA with incorporated SCCs (Irish law and courts), UK and Swiss addenda⁶	Published as part of the Terms of Service; a DPA is available for customers who need a formal contract⁶³³	Region choice pins Postgres, Auth, and Storage; the GDPR page itself flags backups, logs, Edge Function execution, exports, and subprocessors as outside the pin¹
PCI DSS, GDPR badges	Listed on the Trust Center (published 2026-07-30) alongside SOC 2, ISO 27001, HIPAA³⁵	Trust Center	PCI DSS scope is not documented anywhere public - do not assert coverage without the report

Two honest tensions to carry into an audit:

The SOC 2 page says “All data will remain within the chosen region,” while the GDPR page says backups, logs, Edge Function execution, and subprocessors affect residency.⁹¹ The first is a claim about the platform’s primary data stores; the second is the full picture. Contract to the second.
HIPAA on managed Supabase is a well-trodden path (BAA, add-on, High Compliance checks surfaced in Security Advisor), but PHI still inherits every caveat in the per-surface map - keep it out of public buckets, broadcasts, and function logs.¹⁰²⁴

The legal frame: DPA, SCCs, and the CLOUD Act

The DPA (Version 1, 1 August 2026) makes Supabase Pte. Ltd, a Singapore entity, the contracting party and data importer, and incorporates the EU SCCs with Irish governing law and courts, plus UK and Swiss addenda.⁶ Its residency clause starts from the opposite default and then qualifies twice over: “Supabase may Process Covered Data anywhere that Supabase or its Sub-processors maintain facilities,” and where the customer directs a specific region, Supabase “shall ensure that such Covered Data is stored and primarily Processed in that region unless otherwise required to comply with Customer’s additional instructions, applicable law or as necessary to provide Services requested by Customer.”⁶ Both qualifiers matter: “primarily” is what the per-surface map above quantifies, and the services carve-out is broad enough to cover the global surfaces in it.

The subprocessor list (1 June 2026) is the other half of the frame.⁸ Grouped by role:

Role	Subprocessors
Hosting	Amazon Web Services, Cloudflare, Google, Fly.io, Vercel, Upstash
Support	Supabase, Inc. (the US entity)
User communication	Postmark (ActiveCampaign), Front, HubSpot, Slack, PandaDoc, Notion
Monitoring and tracing	Sentry, Braintrust
Other	GitHub (account sign-in), Atlassian (status page), OpenAI, ConfigCat, Latacora, Sublime Security, Clay, Clazar, Hex

You can subscribe to change notifications for the list. Supabase gives subscribers at least 30 days’ notice of a proposed change to the subprocessors, and an objection has to be raised within 5 days of that notice.⁶ One limitation to know before handing the list to counsel: it carries each subprocessor’s name and role only - no processing locations - so it cannot answer “where does each subprocessor process” on its own.

The jurisdictional question. 18 U.S.C. Section 2713 provides that a covered provider “shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.”¹¹ The statute keys on the provider, not on where the bytes are. The other input is the chain: the subprocessor list places Supabase, Inc. (US) in support, and AWS, Cloudflare, Google and Vercel in hosting, for every managed deployment.⁸ Applying the statute to those parties is a legal determination this doc does not make - take the statute and the list to counsel. The proposed EU Cloud and AI Development Act (COM(2026) 502 final, tabled 3 June 2026, a proposal and not yet law) formalises the same distinction in the other direction. Its explanatory memorandum summarises Article 16 as setting out “a Union cloud computing sovereignty framework consisting of four assurance levels” with requirements in Annex II, and Article 18 as setting out “conditions and a mechanism for a possible recognition of third-countries as providing sufficient assurances to allow for cloud computing services controlled from that third country to become eligible to qualify under Union assurance level 3.”³⁷ Those are the Commission’s words about the Articles, not the operative text, which EUR-Lex does not serve at that URL. The same memorandum names the problem as providers “subject to third-country jurisdictions where laws with an extraterritorial effect apply, including laws mandating data access and transfer.”³⁷ Whether a US-controlled operator could reach level 3 therefore depends on a recognition decision that has not been made - inference from the memorandum, not a quotation.

Deployment models against the three layers

Deployment	Residency	Vendor sovereignty	Jurisdictional sovereignty
Managed, specific region	Yes for Postgres, Auth, Storage¹; not for logs, backups (region undocumented), CDN cache, Realtime payloads, or default function execution	Control plane and support access remain, under DPA terms: least-privilege access, mandatory 2FA, segregated networks, retained audit trails⁶	US-incorporated entities are in the chain⁸
Managed + cross-region replica	Adds a full copy in the replica’s region¹⁹	As above	As above
BYOC (enterprise-negotiated)	No public BYOC documentation exists (checked 2026-08-10), so nothing here can be sourced - ask for the terms in writing	Not documented	Not documented
Self-host (open source)	Every surface is placed by you	No vendor in the chain by construction	Determined by where you run it and who operates it

PrivateLink is orthogonal to all three: it makes the network path private from inside your AWS VPC, and changes nothing about where data is stored or who can be compelled.³⁸ The PrivateLink reference covers what it does buy you. For the client-side edge of the same analysis - Durable Object jurisdiction pins, Regional Services, and why the Worker-to-Supabase hop is public TLS by default - see the Cloudflare Workers + Supabase reference.

Decision guide

Checklist for a managed deployment that must hold a residency line:

Pick a specific region, not a smart group; “Europe” can mean London or Zurich.²
No cross-region read replicas unless the replica’s soil is acceptable.¹⁹
Custom SMTP with a provider whose jurisdiction you accept; the same for SMS and CAPTCHA.²¹²²²³
Keep regulated objects off Storage, or accept that every authorised reader’s PoP holds a copy: private buckets are cached like public ones (measured), signed URLs are cached per token, and tightening a policy does not evict a cached object (measured).²⁵²⁶
No regulated payloads in Realtime Presence or Broadcast - presence state fans out to all connected nodes, broadcast persists for days; postgres_changes is the tight path.⁴
Pin Edge Function execution with x-region where execution location matters; remember pinned requests lose failover.⁵
Treat log residency as undocumented; drain logs to your own endpoint if they must stay in-jurisdiction (a drain adds a copy you control, it does not stop the platform-side one; custom endpoints are unsigned and drain config is dashboard-only), and keep PHI out of logs either way.⁷¹⁰
Put the subprocessor list and its change feed into your vendor register.⁸
If the requirement is that no vendor sits in the chain, the region picker cannot deliver it: the subprocessor list applies to every managed deployment regardless of region.⁸

What to do about it

The checklist above is the contract-facing list. This table is what the measured runs add to it, one imperative per row with the module it rests on; module ids resolve in the residency-facts RUNLOG and the instance-sizing RUNLOG. A row that is a design choice says so.

Practice	Rests on
Read the `recommendations` block of `GET /v1/projects/available-regions?organization_slug=<org>` before choosing a smart group; from a Singapore vantage the platform recommended `americas` / `us-west-2`, its capacity pick for that org; whether a smart-group create lands on the recommended region was not measured.	R01, 2026-08-20; landing not measured
Pass a specific `region` when soil matters and `region_selection` only when capacity matters more: a smart-group code in `region` is a 400 (`Need to use one of available regions`), and `region_selection` works on a normal Pro org (201, `ap-northeast-2`, healthy in 135s).	R02; instance-sizing I02
Vary `expiresIn` when you need distinct signed URLs for one object inside one second; two sign calls in the same second with the same `expiresIn` return the same URL.	R05
Do not treat a policy change as revocation for a cached private object: the tightened policy served the previously-authorised user 200/HIT and denied a never-authorised user on a miss. Change the object key (move or delete and re-upload) or keep regulated objects off Storage; whether delete or move evicts the PoP copy is not measured.	R05c, three runs; the eviction half is not measured
Serve regulated objects through your own policy-checking proxy if they must stay on Storage; the platform CDN re-evaluates policy only on a miss.	design choice; nothing in the lab exercises the proxy
Subscribe at least one Realtime client before relying on SQL `realtime.send()` on a fresh project: with zero partitions the call warns `no partition of relation "messages" found for row` and drops the message; one websocket subscribe created five daily partitions.	R06
Include every user’s nearest PoP in the transfer inventory, not only your own: REST and Storage on a Zurich project answered from SIN for a Singapore caller.	R03
Keep log-drain configuration in a manual runbook and audit it by hand: the published OpenAPI document has zero drain-configuration operations, so it cannot be reproduced from IaC or drift-checked.	R07

Not measured: whether deleting or moving an object evicts the cached private copy at a PoP; the cache TTL for no-cache private objects; the 3-day realtime.messages retention (needs a 4-day-old project); Presence fan-out geography (needs multi-vantage clients); log drain delivery end to end (dashboard-gated); whether a pinned Edge Function invocation is re-routed on failure (R04 measured placement only).

What the docs do not answer

Every place this doc says a thing is not documented is a question someone has to ask. Put them to Supabase in writing before a residency commitment goes into a contract, and keep the answers in the agreement rather than in a support thread.

Ask	Why it matters	Where the gap shows up
Which region holds daily backups and PITR WAL archives?	Backups are the largest copy of the database and sit outside the region pin¹	The backups page names no region, only “durable cloud storage, such as S3”¹⁸
Where is the log store hosted?	Logs are extracted out of the project by design⁶ and can carry request bodies and identifiers; a drain adds a copy you control but does not move the platform-side store	The logs page states retention and engine, never location³⁰
What region does a preview branch run in?	A branch is a separate instance with its own credentials³⁴	Branching docs are silent on placement
Where does the control plane run, and which subprocessor hosts it?	It holds project metadata and the support access path⁶	Vercel and Fly.io appear as hosting subprocessors with no service mapping⁸
Who operates the default Auth SMTP service, and where?	It handles addresses and message bodies until you set custom SMTP²¹	The operator is never named; Postmark appears on the subprocessor list for user communication⁸
Where do hosted image transformations execute?	Derivatives are generated from your objects²⁷	Only imgproxy is named, not the execution location
Where does the Shared Pooler run below the region tag in its hostname?	It terminates connections and sees credentials in transit²⁸	The hostname carries a region; nothing documents the placement
What is the scope of the PCI DSS listing?	The Trust Center lists it alongside SOC 2 and ISO 27001³⁵	No public document states its scope
For BYOC: who operates the control plane, under whose IAM, with what access?	There is no public BYOC documentation at all (checked 2026-08-10)	Everything about it is contractual
What do the dashboard AI features (assistant, inline SQL completions) send, and where is it processed?	Schema and query text are potentially sensitive; OpenAI and Braintrust appear on the subprocessor list with no data-flow description⁸	No public page states what is sent, where it is processed, or what the opt-out levels do
Where are Edge Function secrets stored, and do they replicate?	Upstash appears as a hosting subprocessor with no service mapping⁸	The function-secrets docs do not state a storage location or replication behavior
Can support access be restricted to personnel in a particular country?	A firm carrying privilege obligations needs the answer in writing	The DPA contracts least-privilege, audited access but is silent on personnel geography⁶
How long does a cached private object survive at a PoP after authorisation ends?	Measured: the CDN serves it without re-evaluating the policy on a hit; the window is the eviction TTL, which is not documented	The CDN pages document invalidation propagation (~60s) but not TTL for `no-cache` private objects²⁵

Reading the numbers

Claim in this doc	How it was checked
17 specific regions, 3 smart groups, no ME/ID/MY region	Measured 2026-08-10, re-measured 2026-08-20: `GET /v1/projects/available-regions?organization_slug=<org>` (bare call 400s; shape `{ recommendations, all }`)
Smart group code rejected in the `region` field of project creation	Measured 2026-08-10, re-confirmed 2026-08-20: `POST /v1/projects` with `"region": "emea"` -> 400, `Need to use one of available regions`; the documented field for a smart group is `region_selection`
Cloudflare edge in front of project APIs, caller-nearest PoP	Measured 2026-08-10 against `eu-central-1`, re-measured 2026-08-20 against `eu-central-2` (Zurich): `server: cloudflare`, `cf-ray ...-SIN` on REST and Storage responses, from Singapore
Edge Functions default to user-nearest region; pinnable	Measured 2026-08-10 against `eu-central-1`, re-measured 2026-08-20 against Zurich: `x-sb-edge-region: ap-southeast-1` by default, project region with the `x-region` header; documented at regional-invocation
Storage CDN cache matrix (public miss-then-hit; signed per-token keying; private cached per-object not per-user; cached private object served after policy revocation)	Measured 2026-08-20 against Zurich, three consecutive runs: `cf-cache-status` sequences MISS->HIT, HIT-on-repeat / MISS-on-new-token, user2-first-read HIT, and denied-user 200/HIT vs never-authorized 400/DYNAMIC. The per-user-miss claim on the CDN fundamentals page did not reproduce
Realtime `realtime.messages` daily partitioning; lazy partition creation; SQL `realtime.send` warns and drops pre-subscribe	Measured 2026-08-20 against Zurich: pg catalog + websocket subscribe; 5 daily partitions (+/-2 days) under `supabase_realtime_messages_publication`; 3-day retention not observable on a fresh project
No log-drain configuration in the published Management API	Measured 2026-08-20: zero drain-config operations across the entire published OpenAPI document (enumerated, not name-probed); drains are dashboard-only
Region pins Postgres, Auth, Storage; backups/logs/functions/subprocessors outside	Documented: GDPR compliance page
Backup and PITR mechanics; S3; 2-minute RPO; PITR replaces daily backups	Documented: backups page
Replica is a full physical copy; Auth/Storage/Realtime stay on primary	Documented: read-replicas getting-started page (copy); read-replicas index (service routing)
Realtime is a global cluster	Documented: Realtime architecture page
Logs extracted to segregated systems; ClickHouse since June 2026; retention by plan	Documented: DPA Schedule 1; logs page; pricing page
DPA entity, SCCs, clause 6.1 wording	Documented: DPA v1 (2026-08-01)
Subprocessor roles and names	Documented: subprocessor list PDF (2026-06-01)
SOC 2 / ISO 27001 / HIPAA plan scoping	Documented: SOC 2, HIPAA projects, HIPAA compliance, security overview, shared-responsibility pages; Trust Center
Backup storage region; log store region; branch region; control-plane hosting location; default SMTP operator; hosted image-transform location; AI-feature data flow; Edge Function secret storage; support personnel geography	Not documented as of 2026-08-20 - stated as unknown rather than asserted

The 2026-08-10 rows were run once each, against one account, from one vantage; the 2026-08-20 rows re-ran them against a Zurich project and added the storage and realtime matrices, from a re-runnable test harness rather than a session transcript. The region catalogue and the smart-group rejection are platform facts that drift slowly; the edge headers are per-request facts consistent across every response observed. Re-run any of them cheaply before quoting them in a contract.

References

Supabase, “GDPR compliance,” Supabase Docs. https://supabase.com/docs/guides/security/gdpr-compliance ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰
Supabase, “Regions,” Supabase Docs. https://supabase.com/docs/guides/platform/regions ↩ ↩² ↩³ ↩⁴ ↩⁵
Supabase, “Supabase for Platforms,” Supabase Docs. https://supabase.com/docs/guides/integrations/supabase-for-platforms ↩ ↩² ↩³
Supabase, “Realtime architecture,” Supabase Docs. https://supabase.com/docs/guides/realtime/architecture ↩ ↩² ↩³ ↩⁴ ↩⁵
Supabase, “Regional invocation,” Supabase Docs. https://supabase.com/docs/guides/functions/regional-invocation ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Supabase, “Data Processing Addendum (Version 1, August 1, 2026),” Supabase Legal. https://supabase.com/legal/dpa ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷
Supabase, “Log drains,” Supabase Docs. https://supabase.com/docs/guides/monitoring-and-debugging/log-drains ↩ ↩² ↩³
Supabase, “Subprocessor List (June 1, 2026),” Supabase Legal. https://supabase.com/legal/subprocessor-list/June-1-2026.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵
Supabase, “SOC 2 compliance,” Supabase Docs. https://supabase.com/docs/guides/security/soc-2-compliance ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Supabase, “HIPAA projects,” Supabase Docs. https://supabase.com/docs/guides/platform/hipaa-projects ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Legal Information Institute, “18 U.S.C. Section 2713 - Required preservation and disclosure of communications and records,” Cornell Law School. https://www.law.cornell.edu/uscode/text/18/2713 ↩ ↩²
Supabase, “Change the region of a Supabase project,” Supabase Docs. https://supabase.com/docs/guides/troubleshooting/change-project-region-eWJo5Z ↩
Amazon Web Services, “AWS Regions,” AWS Documentation. https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html ↩
Republik Indonesia, “Peraturan Pemerintah Nomor 71 Tahun 2019 tentang Penyelenggaraan Sistem dan Transaksi Elektronik,” Pasal 20, JDIH Komdigi. https://jdih.komdigi.go.id/produk_hukum/view/id/695/t/peraturan+pemerintah+nomor+71+tahun+2019 ↩
Supabase, “Vault,” Supabase Docs. https://supabase.com/docs/guides/database/vault ↩ ↩²
Supabase, “Cron,” Supabase Docs. https://supabase.com/docs/guides/cron ↩
Supabase, “Queues,” Supabase Docs. https://supabase.com/docs/guides/queues ↩
Supabase, “Backups,” Supabase Docs. https://supabase.com/docs/guides/platform/backups ↩ ↩² ↩³ ↩⁴
Supabase, “Read replicas: getting started,” Supabase Docs. https://supabase.com/docs/guides/platform/read-replicas/getting-started ↩ ↩² ↩³
Supabase, “Read replicas,” Supabase Docs. https://supabase.com/docs/guides/platform/read-replicas ↩ ↩²
Supabase, “Auth SMTP,” Supabase Docs. https://supabase.com/docs/guides/auth/auth-smtp ↩ ↩² ↩³ ↩⁴
Supabase, “Phone login,” Supabase Docs. https://supabase.com/docs/guides/auth/phone-login ↩ ↩²
Supabase, “Auth CAPTCHA,” Supabase Docs. https://supabase.com/docs/guides/auth/auth-captcha ↩ ↩²
Supabase, “Shared responsibility model,” Supabase Docs. https://supabase.com/docs/guides/deployment/shared-responsibility-model ↩ ↩² ↩³
Supabase, “CDN fundamentals,” Supabase Docs. https://supabase.com/docs/guides/storage/cdn/fundamentals ↩ ↩² ↩³ ↩⁴ ↩⁵
Supabase, “Smart CDN,” Supabase Docs. https://supabase.com/docs/guides/storage/cdn/smart-cdn ↩ ↩² ↩³ ↩⁴ ↩⁵
Supabase, “Image transformations,” Supabase Docs. https://supabase.com/docs/guides/storage/serving/image-transformations ↩ ↩²
Supabase, “Connect to your database,” Supabase Docs. https://supabase.com/docs/guides/database/connecting-to-postgres ↩ ↩² ↩³
Supabase, “Edge Functions architecture,” Supabase Docs. https://supabase.com/docs/guides/functions/architecture ↩
Supabase, “Logging and observability,” Supabase Docs. https://supabase.com/docs/guides/monitoring-and-debugging/logs ↩ ↩² ↩³ ↩⁴
Supabase, “Pricing and fees,” Supabase. https://supabase.com/pricing ↩
Supabase, “Metrics API,” Supabase Docs. https://supabase.com/docs/guides/monitoring-and-debugging/metrics ↩
Supabase, “Security at Supabase,” Supabase Docs. https://supabase.com/docs/guides/security ↩ ↩² ↩³
Supabase, “Branching,” Supabase Docs. https://supabase.com/docs/guides/deployment/branching ↩ ↩²
Supabase, “Supabase Trust Center,” SecurityPal. https://trust.supabase.io/ ↩ ↩² ↩³
Supabase, “HIPAA compliance and Supabase,” Supabase Docs. https://supabase.com/docs/guides/security/hipaa-compliance ↩
European Commission, “Proposal for a Cloud and AI Development Act, COM(2026) 502 final,” EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2026:0502:FIN ↩ ↩²
Supabase, “PrivateLink,” Supabase Docs. https://supabase.com/docs/guides/platform/privatelink ↩