Migrate a Supabase Project to Another Region or Org

Supabase lets you transfer a project to another organization natively from the dashboard, but it does not support changing the region of an existing project. To move a project to a new region, you have to create a fresh project in the target region and migrate the schema, data, storage, and functions yourself — then update every URL, API key, and secret that pointed at the old project. This guide covers both paths: the built-in organization transfer and the full manual region migration, including what carries over, what breaks, and how to keep downtime short.

Can you change the region of an existing Supabase project?

No. A Supabase project is provisioned on physical infrastructure in one region and stays there for its entire life. Supabase's own troubleshooting docs are explicit: the process to change region is to create a new project in the desired region and migrate your existing project into it.

Two features sound like they should solve this, but don't:

• Project transfer moves a project between organizations — the docs state directly that transfers "cannot be used to transfer between different regions."
• Duplicate project / restore to another project (paid plans with physical backups) clones your database into a new project, but the new project is created in the same region as the source, deliberately, for data-residency compliance.

So if your goal is us-east-1 → eu-central-1, both native features are dead ends. You're doing a migration.

How do you transfer a Supabase project to another organization?

If you only need to change ownership — moving a project from your personal org to a company org, handing a client project over, or consolidating billing — Supabase has you covered natively. From your project's General settings, initiate a project transfer.

Requirements and caveats, per the official docs:

• You must be an Owner of the source organization and at least a Member of the target organization.
• The project keeps its URL, API keys, database, storage, edge functions, custom domain, and add-ons (Compute, PITR, IPv4, etc.). Billing responsibility moves to the target org.
• The transfer is blocked while the project has an active GitHub integration, log drains configured, or project-scoped roles pointing at it (Team/Enterprise). Disconnect these first, then reconnect after.
• Moving from a paid org to a Free Plan org can cause a short 1–2 minute downtime, and you lose paid features (PITR, daily backups beyond the free window, compute add-ons). Upgrade the target org first if you can.
• Your own role may effectively downgrade — Owner in the old org doesn't make you Owner in the new one.

For a pure org move, stop here. Nothing else in this article applies, and doing a manual migration instead would be strictly worse: you'd lose your project URL and keys for no benefit.

Why do teams move Supabase projects to an EU region?

The most common motive we see is data residency. If your users are in the EU and your project was created in a US region (the default is easy to click through), GDPR reviews, enterprise procurement questionnaires, and DPAs eventually force the question: where does the data physically live? Supabase runs regions across Europe (Frankfurt, London, Paris, Stockholm, and more), so the fix is available — it's just not a toggle.

Other reasons that trigger the same migration:

• Latency: your users and your app servers are in Europe or Asia, but the database round-trips to Virginia on every request.
• Compliance beyond GDPR: industry rules or customer contracts that mandate a specific jurisdiction.
• A region picked by accident on day one that only starts hurting at scale.

Whatever the motive, the mechanics are identical: new project, full migration, cutover.

How do you migrate a Supabase project to another region, step by step?

Here is the sequence that works. It follows Supabase's official backup and restore guide for the database, with the platform-level pieces added around it.

1. Create the target project in the new region, same organization (or the target organization, if you're changing both at once — creating the project directly in the destination org saves a transfer later). Match the Postgres major version of the source.

2. Migrate the database structure. Two options:

• SupaClone connects to both projects via Supabase OAuth (no connection strings) and clones the full structure — schemas, tables, RLS policies, functions, triggers, indexes, views, enums, extensions — into the fresh target using native pg_dump/pg_restore with a baseline-aware plan that skips Supabase-managed schemas (auth, storage, realtime). Every run ends in a field-by-field verification report, which doubles as your migration checklist: it lists exactly what was cloned, what was skipped, and which manual steps (like secrets) remain. Trying to restore a naive dump over the managed schemas is the classic way region migrations fail — our pg_dump and pg_restore guide walks through the specific errors.
• Supabase CLI, if you prefer doing it by hand:

supabase db dump --db-url "$SOURCE_DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$SOURCE_DB_URL" -f schema.sql

3. Migrate the data. SupaClone clones structure only today (data clones are coming soon), so data moves via the CLI:

supabase db dump --db-url "$SOURCE_DB_URL" -f data.sql --use-copy --data-only

Restore in one transaction, with triggers disabled so they don't re-fire on already-processed rows:

psql --single-transaction --variable ON_ERROR_STOP=1 \
  --file roles.sql --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "$TARGET_DB_URL"

If you cloned the structure with SupaClone first, skip roles.sql/schema.sql here and restore data.sql alone.

4. Migrate Storage and Edge Functions. Neither is included in a database dump. Storage objects need to be copied via the Storage API; Edge Functions are re-deployed with supabase functions download + supabase functions deploy. SupaClone's Storage and Edge Functions add-ons cover the buckets, files, policies, and function code — details in cloning Storage and Edge Functions.

5. Recreate everything that never leaves the old project — see the table below.

6. Cut over. Update SUPABASE_URL, the anon/publishable key, and the service-role key in your app's environment, redeploy, and repoint your custom domain.

What carries over and what must be recreated?

This is where region migrations bite. An org transfer keeps essentially everything; a region migration keeps almost nothing platform-level:

The right-hand column is why you should keep the old project alive in read-only for a week or two after cutover — it's your rollback and your reference for every setting you forgot.

Secrets deserve emphasis: no tool can copy them, because Supabase's Management API never exposes secret values. SupaClone is explicit about this — secrets are never copied and instead show up as named manual steps in the clone report, so nothing silently stays unset.

How much downtime does a Supabase region migration cause?

An org transfer is near-zero downtime (worst case 1–2 minutes when downgrading plans). A region migration's downtime is the window between freezing writes on the old project and completing cutover on the new one. You cannot safely let users write to the old database while you're dumping it — anything written after the dump starts is lost.

Ways to keep the window small:

• Do the structure ahead of time. Clone the schema, RLS, functions, and Edge Functions days before cutover and verify them. On migration day, only the data dump/restore is on the clock. This is the same pattern as setting up a staging environment — the target is just promoted to prod at the end.
• Rehearse against a throwaway project and time the data restore. Dump/restore duration scales with database size; a few GB is minutes, hundreds of GB is hours — you want to know which before you announce a maintenance window.
• Pause external writers: cron jobs, queues, webhooks from third parties.
• Verify before you flip DNS. Row counts, a smoke test of auth sign-in (new JWT secret means all sessions are invalid), one write per critical table, Storage reads.
• Expect a long tail of session resets even after a clean cutover — every logged-in user gets logged out because the JWT secret changed.

Where does SupaClone fit in a region migration?

SupaClone is the structure step — the part where manual migrations most often go wrong, because Supabase's managed schemas make naive pg_dump/pg_restore fail in non-obvious ways. It clones your source project's complete structure into the fresh target project in the new region (the source is only ever read), and the verification report tells you field-by-field what made it across and what's left as a manual step. Data still moves via the CLI for now, and platform settings still need your hands — but the report means you're working from a checklist instead of memory. Every plan includes a 14-day free trial with one successful clone, which is exactly one region migration's worth. For the broader picture of when and how to clone a project at all, start with the complete guide to cloning a Supabase project.

FAQ

Can I change the region of a Supabase project without creating a new one?

No. Supabase projects are bound to their region at the infrastructure level. The officially documented path is to create a new project in the target region and migrate schema, data, storage, and functions into it, then update your app's URL and keys.

Does transferring a Supabase project to another organization change its URL or API keys?

No. An org transfer keeps the project URL, API keys, database, storage, custom domain, and add-ons intact — only ownership and billing move. That's why org transfers are near-zero downtime while region migrations require a full cutover.

Do Supabase project transfers work on the Free Plan?

Yes, transfers themselves are free, but the target org's plan applies afterward. Moving a paid project into a Free Plan org can cause 1–2 minutes of downtime and drops paid features (PITR, compute add-ons), and Free Plan orgs are limited to two active projects. Supabase recommends upgrading the target org first.

Are Auth users migrated when I move regions?

Yes — auth users, including hashed passwords, live in the auth schema and come along with a full database dump. But the new project has a new JWT secret, so all existing sessions are invalidated and users must sign in again. OAuth provider credentials (Google/GitHub client IDs and secrets) must be re-entered manually and callback URLs updated.

Is moving to an EU region enough for GDPR compliance?

It addresses data residency — your database, storage, and backups physically live in the EU — which is often the concrete requirement in DPAs and procurement reviews. Full GDPR compliance also involves processing agreements, retention policies, and subprocessor documentation; the region move is necessary but not sufficient on its own.