SupaShift Documentation

SupaShift is a database migration tool that uses pg_dump and psql to copy PostgreSQL databases between platforms. It's a copy, not a move — your source database remains untouched.

SupaShift copies your entire database schema, data, functions, and policies. Some platform-specific features like Auth, Storage, and Edge Functions require separate setup after migration.

Prerequisites

Before starting a migration, make sure you have:

Access credentials for both source and destination databases
Database passwords (or connection strings)
An empty destination project or database
Network access between both databases (not behind incompatible firewalls)

Quick Start

1

Select platforms

Choose your source and destination database platforms from the dropdown.

2

Enter connection details

Provide the host, port, database name, and credentials for both databases.

3

Configure migration

Choose whether to include extensions, roles, and other options.

4

Migrate

Click Run Migration and wait for completion. Verify with the post-migration checklist.

Supabase to Supabase

The most common migration path. Copy your Supabase project to a new Supabase project — useful for upgrading plans, moving regions, or creating staging environments.

Create an empty Supabase project first. Go to supabase.com/dashboard → New Project → set a project name and database password → wait for provisioning to complete.

Finding your connection details

  1. Go to Dashboard → Settings → Database
  2. Click Connect
  3. Select the Session pooler tab

Example connection

Host:aws-0-us-east-1.pooler.supabase.com
Port:5432
Database:postgres
User:postgres.abcdefghijklmnop

Supabase to AWS RDS

Migrate from Supabase to a self-managed AWS RDS PostgreSQL instance for full control over infrastructure and scaling.

Provisioning RDS

  1. Go to AWS Console → RDS → Create database
  2. Select PostgreSQL as the engine
  3. Choose your instance size (db.t3.micro for testing, db.t3.medium+ for production)
  4. Enable Public access for initial migration
  5. Set your master username and password

Finding your endpoint

  1. Go to RDS → Databases → select your instance
  2. Find Endpoint & port in the connectivity section

Example endpoint

Host:mydb.xxxxxxxxxx.us-east-1.rds.amazonaws.com
Port:5432
Database:postgres

Security Groups

Ensure your RDS security group allows inbound traffic on port 5432 from your Supabase project's IP or from 0.0.0.0/0 (temporarily) during migration. You can restrict it afterward.

AWS RDS to Supabase

Popular for teams wanting to move from self-managed RDS to Supabase for managed Auth, Storage, and Realtime.

Supabase free tier limits

The free tier includes 500MB of database storage. Make sure your RDS data fits within your Supabase plan limits before migrating.

Important notes

  • Do not migrate the auth, storage, or realtime schemas. These are managed by Supabase internally.
  • RLS policies will be migrated but must be re-enabled on the destination.
  • Edge Functions and Storage Buckets need separate setup after migration.
  • Auth settings, API keys, and redirect URLs must be configured manually.

Supabase to Neon

Neon is a serverless Postgres platform with branching, autoscaling, and a generous free tier. Great for dev environments and preview deployments.

Steps

  1. Create a project at neon.tech
  2. Go to Settings → Connection Details
  3. Select the Pooled connection tab
  4. Copy the connection string and use it in SupaShift

Example connection

Host:ep-cool-darkness-123456.us-east-2.aws.neon.tech
Port:5432
Database:neondb
User:neondb_owner

Any Postgres to Any Postgres

SupaShift works with any PostgreSQL database. As long as both source and destination are Postgres-compatible, the migration will work.

Supported platforms

Supabase
AWS RDS / Aurora
Neon
Firebase (via pg conversion)
Vercel Postgres
Railway
Render
DigitalOcean
Google Cloud SQL
Azure Database
Crunchy Data
Timescale Cloud
Any self-hosted PostgreSQL

What Gets Migrated

SupaShift handles the database layer. Platform-specific features need separate setup.

Automatically migrated

  • Schema and tables
  • Row Level Security policies
  • Functions and triggers
  • All data rows
  • Views
  • Enum types
  • Indexes
  • Roles and grants

Requires manual setup

  • Storage buckets and files
  • Edge Functions
  • Auth settings and providers
  • API keys and secrets
  • Realtime subscriptions
  • Compute and plan settings
  • Extensions (must enable first)
  • Webhooks and integrations

Post-Migration Checklist

Complete these steps after a successful migration:

1
Update API keys and service role keys
2
Re-enable Storage if it was disabled
3
Redeploy Edge Functions
4
Re-enable Realtime on tables that need it
5
Update redirect URLs in auth settings
6
Verify row counts match source and destination
7
Test a few queries to ensure data integrity
8
Check RLS policies are working correctly
9
Update connection strings in all environments (staging, production, local)
10
Keep the old database running for at least 48 hours before decommissioning

Troubleshooting

Common issues and how to resolve them:

Cannot connect

Check host, port, user, and password. For Supabase, use the Session Pooler connection (not direct). Verify your project is not paused on the free tier.

Permission denied for schema public

The migration user needs CREATEDB or SUPERUSER privileges. On Supabase, the postgres user has these by default. On RDS, ensure the master user is being used.

relation already exists

The destination database already has tables. Create a completely empty project or database before starting the migration.

extension not available

Some PostgreSQL extensions must be enabled manually on the destination before migration. Enable required extensions first, then re-run the migration.

sequence value mismatch

After data import, auto-increment sequences may be out of sync. Reset them with: SELECT setval('table_id_seq', (SELECT MAX(id) FROM table));

FAQ

Is SupaShift free?

Yes. SupaShift is open source and free to use. You only pay for your database hosting on the source and destination platforms.

Does it work on the free tier?

Yes. SupaShift works with Supabase, Neon, and other free-tier databases. Just ensure your project is not paused and you have enough storage for the data being migrated.

How long does a migration take?

Depends on data size. Small databases (under 100MB) typically migrate in under a minute. Larger databases (1GB+) may take several minutes. Network speed between source and destination is the main factor.

What about auth users?

Auth users are stored in the auth schema, which is not migrated by default. You will need to export and import auth users separately using Supabase CLI or direct SQL queries on the auth schema.

Can I migrate specific tables only?

Not in the current version. SupaShift migrates the entire database. If you need specific tables, create a new empty database, copy only the tables you need, then migrate that database.