Migrate from Amazon RDS

Amazon RDS for PostgreSQL (and Aurora PostgreSQL) moves to SupaHost with pg_dump and a restore. The two RDS-specific steps are reaching the database, which usually sits inside a VPC, and leaving out AWS-only extensions and roles. After that it's the same as any Postgres move.

Plan

• Size. The database must fit your plan's shared quota (8 GB Builder, 25 GB Pro, 50 GB Business). For large databases, Business is the practical choice because you can restore directly over the SSH tunnel.
• Network. Run the dump from a machine that can reach the RDS endpoint: an EC2 instance in the same VPC, a bastion host, or your laptop if the instance is publicly accessible and its security group allows your IP on port 5432.
• App access. EC2, ECS or Lambda code that connects with a Postgres driver will need to use the Data API instead, since a SupaHost project's Postgres isn't reachable over the internet. Lambda in particular fits the HTTP model well.

Export from RDS

pg_dump -Fc --no-owner --no-privileges -n public \
  -h fleet-db.c9abcdxyz.eu-west-2.rds.amazonaws.com -U fleet_admin -d fleet \
  -f fleet.dump

Use pg_dump 17. --no-owner --no-privileges strips grants to rds_superuser and other RDS roles. -n public keeps only your application schema; if you use more schemas, add one -n per schema.

Transform

Check which extensions the source uses:

select extname, extversion from pg_extension order by 1;

Skip AWS-only ones such as aws_s3, aws_commons and aws_lambda; any functions that call them need rewriting (for example, an S3 export can become an Edge Function). Create the rest in the target project, in the extensions schema:

create extension if not exists postgis with schema extensions;
create extension if not exists pgcrypto with schema extensions;

Load

Business and Enterprise:

ssh -N -L 6543:127.0.0.1:5432 [email protected] &
pg_restore --no-owner --no-privileges -j 4 \
  -d "postgresql://postgres:<password>@127.0.0.1:6543/p_app_one" fleet.dump

-j 4 restores tables in parallel. The password comes from Dashboard → your project → Connect → Database → Show connection string.

Builder and Pro: restore into a temporary Supabase Cloud project and use the one-click import, or, for small databases, run the schema in Studio's SQL editor and load tables from CSV or through a supabase-js script with the service_role key.

After loading

-- every public table is reachable through the Data API: lock it down
alter table public.vehicles enable row level security;
alter table public.trips enable row level security;
analyze;

Add policies, then recreate any scheduled work you ran with EventBridge or Lambda as pg_cron jobs:

select cron.schedule('close-trips', '0 * * * *', $$
  update public.trips set status = 'closed'
  where status = 'open' and ended_at < now() - interval '1 hour'
$$);

Switch the app and verify

Replace the RDS host and credentials with SUPABASE_URL and the service_role key (server code) or anon key (client code), and move queries to supabase-js or rpc(). Compare select count(*) per table between RDS and SupaHost, test the main flows, and take a final RDS snapshot before you delete the instance.

Related

• Importing data (CSV, SQL dumps)
• Postgres extensions
• SSH access and direct Postgres
• Scheduled jobs with pg_cron