Migrate One Supabase Project to Another Free Tier

Migrate One Supabase Project to Another Free Tier

Migrate One Supabase Project to Another Free Tier

Moving one Supabase project to another is one of those tasks that sounds easy until you actually try it. There is no single “duplicate project” button in the dashboard, and what you need to do depends heavily on whether you are on the free plan or a paid plan. This guide covers every scenario, including how to transfer a project to a different organization and how to copy everything without losing your database structure or data.


Why You Might Need to Move Your Supabase Project

There are more reasons than you might expect to migrate a Supabase project:

  • Moving from a personal account to a team organization
  • Duplicating a project to create a staging or development environment
  • Transferring ownership to a client account
  • Upgrading to a new project with a different region or compute size
  • Starting fresh on a new account without rebuilding your backend from scratch

Whatever your scenario, the process follows the same core steps. The main difference is whether you use the built-in dashboard feature or the manual CLI route.


The Easy Way: Transfer a Project to a Different Organization (Same Account)

If you want to move your project to a different organization within the same Supabase platform, this is the easiest path. You do not need to touch the database at all.

Here is how to do it:

  1. Open your project in the Supabase dashboard
  2. Go to Settings > General
  3. Scroll down to find the Transfer Project option
  4. Select the destination organization from the dropdown
  5. Confirm the transfer

The project, its database, its API keys, its URL, and all its settings move instantly. Billing and usage shift to the destination organization from that point. This is the cleanest way to hand a project to a client or move it from a personal free plan to a team account without any downtime or restore process.

Important: Both the source organization and the destination organization must meet the plan requirements for the project. If your original project is on a paid plan, the destination organization needs to also be on a paid plan or have enough compute and disk allocation.


How to Duplicate a Project to a New Account (Free Plan)

If you need to copy your Supabase database to a completely different account, the dashboard transfer feature will not help here. You need to back up the database from the source and restore it to a new project. This is the method free plan users rely on, and it works well when done in the right order.

What You Need Before You Start

  • Supabase CLI installed locally
  • PostgreSQL tools (psql and pg_dump) matching your Supabase Postgres version
  • Connection strings from both the source  and the new project
  • Access to the Supabase dashboard on both accounts

Step 1: Create a New Project in the Destination Account

Log into your destination Supabase account and create a new project. Choose the region closest to your users, set a strong database password, and note the new project’s API URL and anon key from Settings > API. You will need these later to update your app config.

Step 2: Get the Database Connection URLs

In your source project, go to Settings > Database > Connect. Copy the Session Pooler URL for IPv4 compatibility. Do the same in your new project. Save both as environment variables:

export SOURCE_DB_URL="postgresql://postgres.[old-id]:[password]@pooler.supabase.com:5432/postgres" export NEW_DB_URL="postgresql://postgres.[new-id]:[password]@pooler.supabase.com:5432/postgres"

Step 3: Back Up the Source Database

Use the Supabase CLI to create three backup files from your source project. The order matters: roles, then schema, then data.

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

Each file is a logical backup of a specific layer of your database. Together they capture everything: your tables, views, RLS policies, functions, triggers, and all row-level data.

Step 4: Prepare the New Project

Before you restore, make sure the new project is ready:

  • Enable any Postgres extensions your source project used (Database > Extensions). If these do not exist in the new environment before the restore, the schema file will throw errors
  • Enable database webhooks if your original project used them
  • Note the infrastructure version to ensure it matches your local pg_dump version

Step 5: Restore to the New Project

Run the restore in three passes. Use --single-transaction to ensure the process rolls back cleanly if any error occurs:

psql --single-transaction --variable ON_ERROR_STOP=1 \ --file roles.sql --dbname "$NEW_DB_URL" psql --single-transaction --variable ON_ERROR_STOP=1 \ --file schema.sql --file data.sql --dbname "$NEW_DB_URL"

Step 6: Verify and Update Your App

Once the restore is complete:

  • Open the Table Editor and confirm tables and row counts match the source
  • Check Authentication > Policies to see that all RLS policies are in place
  • Update your app’s environment variables with the new project URL and API keys
  • Re-enable Realtime replication for any tables that need it (this is off by default in every new Supabase project)

Moving a Project to a Different Region

Supabase does not currently support in-place region migration. If you need to move your project to a different region, the process is the same as the account-to-account migration above. Create a new project in the target region, back up your source, and restore.

The one thing to plan for here is downtime. During the migration window your app will need to point at the source until the restore is verified, then you swap the URL and API keys in your config to point at the new project. For most small Supabase on the free plan, this window is under 15 minutes.


What Does Not Transfer Automatically

Whether you use a db dump or a paid plan restore, some resources always need manual migration:

ComponentTransferred via DumpAction Needed
Tables, views, schemaYesNone
RLS policiesYesNone
Postgres extensionsNoRe-enable in dashboard
Edge functionsNoRedeploy via CLI
Supabase Storage filesNoDownload and re-upload
Auth usersNoMigrate auth.users separately
API URL and keysNoUpdate in app settings
Realtime replicationNoRe-enable per table
Custom compute settingsNoReconfigure in new project

Use GitHub to version-control your edge functions and schema migrations so that redeploying to a new environment is fast and consistent.


Additional Resources and Learning

If you want to go deeper on any of these steps, the official Supabase docs cover the following topics in detail:

  • Migrating within Supabase
  • Database Backups guide
  • Backup and Restore using the CLI

For video walkthroughs, there are also community-produced guides on YouTube that show the full duplicate process step by step.


Moving one Supabase instance to another does not need to be stressful. With the free plan, the Supabase CLI gives you everything you need to create a reliable backup and restore it to a new environment in under 20 minutes. With a paid plan, the process gets even easier with one-click restore to a new project and daily backup snapshots. The key is knowing which method fits your scenario and following the steps in the right order.