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:
- Open your project in the Supabase dashboard
- Go to Settings > General
- Scroll down to find the Transfer Project option
- Select the destination organization from the dropdown
- 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 (
psqlandpg_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_dumpversion
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:
| Component | Transferred via Dump | Action Needed |
|---|---|---|
| Tables, views, schema | Yes | None |
| RLS policies | Yes | None |
| Postgres extensions | No | Re-enable in dashboard |
| Edge functions | No | Redeploy via CLI |
| Supabase Storage files | No | Download and re-upload |
| Auth users | No | Migrate auth.users separately |
| API URL and keys | No | Update in app settings |
| Realtime replication | No | Re-enable per table |
| Custom compute settings | No | Reconfigure 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.
