Supabase to AWS migration: what it costs, what moves, and when to stay.

The database is the easy part: it's plain Postgres, and logical replication to RDS keeps downtime to a short write pause. The work is in the services around it, so a Supabase migration is five small moves, not one big one.

Every Supabase project is a Postgres database plus a set of open-source services Supabase runs for you. Its own self-hosting guide lists them, among others: Auth, PostgREST, Realtime, Storage, the Edge Runtime for functions, Supavisor for connection pooling and the Studio dashboard. Moving to AWS means deciding, one by one, what replaces each of them, and which ones you keep.

Pro starts at $25 a month and Team at $599, but Supabase cost per month is a plan fee, plus a compute size per project, plus usage over the plan's quotas. The plan fee is the smallest part once you grow.

Four things move a Supabase bill more than the plan does:

• Compute is per project. The $10 credit covers one Micro. A staging project, or a second app, is another compute line.
• Users over 100,000. At $0.00325 each, 200,000 extra MAU is $650 a month.
• Point-in-time recovery. $100 a month per 7 days of retention. Without it you have daily backups only.
• Egress past 250 GB, at $0.09 per GB uncached and $0.03 cached.

Spend caps are on by default on Pro: usage past a covered quota is disallowed until the next billing cycle instead of billed. Compute, PITR and the IPv4 add-on aren't covered by the cap. Two facts matter during a migration: database backups don't include files stored through the Storage API, and the direct database connection is IPv6 unless you buy the IPv4 add-on at $0.0055 an hour (about $4 a month).

Two things stand out. First, at the small size Supabase is very good value and AWS can't match it: the load balancer, NAT gateway and IP addresses cost about $60 before anything runs. Second, Auth decides the medium and large bills. Supabase charges $0.00325 per MAU over 100,000; Cognito Lite charges $0.0055, then $0.0046. A team that moves to AWS and Cognito because "AWS is cheaper" can end up paying more. Running Supabase Auth yourself, or keeping hosted Supabase Auth, avoids that.

There are four: stay on Supabase, split (database to RDS, hosted Supabase Auth kept), self-host Supabase on AWS, or go AWS-native with RDS, ECS, S3 and Cognito or your own auth. "Leave Supabase" covers four quite different projects. Here's how we see them.

If all you want is managed Postgres somewhere else, Neon is a common Supabase alternative: its Launch plan bills $0.106 per compute-unit hour and $0.35 per GB-month of storage, with no monthly minimum, and SOC 2 and HIPAA are listed on its Scale plan. It's a database host, though, not a full Supabase replacement, and it doesn't put the database in your AWS account.

The split is the option teams overlook most. It moves the part that costs money and draws security questions, and leaves the part your users touch alone. You can move Auth later, or never.

We default to RDS for PostgreSQL. It's the closest thing to the single Postgres instance you have on Supabase, and the cheapest to run at startup size. Aurora PostgreSQL makes sense when you want fast failover or several readers; Aurora Serverless v2 bills $0.12 per ACU-hour in us-east-1, which is worth pricing if your load is spiky.

Database in private subnets, one AWS account per environment, every resource in Terraform. Supabase's dashboard was your documentation; the Terraform repo replaces it.

Step 4: migrate Supabase Postgres to RDS with a short write pause.

Use pg_dump and pg_restore for a database of a few GB, and logical replication for anything bigger. This is where Supabase is easier to leave than Heroku (compare our Heroku to AWS migration guide). Supabase documents replicating a project to an external Postgres with native logical replication, so a copy on RDS can stay in sync while Supabase keeps serving traffic.

How to set up logical replication from Supabase to RDS.

1. Schema first. Logical replication doesn't copy the schema. Dump your own schemas with pg_dump --schema-only and apply them to RDS. Leave Supabase-managed schemas out unless that part is moving.
2. Connectivity. Supabase says replication needs a direct connection, not the pooler, and the direct connection is IPv6 unless you enable the IPv4 add-on. An RDS instance in private subnets reaches the internet over IPv4 through a NAT gateway, so turn the add-on on for the weeks of the migration (about $4 a month).
3. Publication and slot on Supabase. Create a publication with your tables and a pgoutput replication slot, as Supabase's guide shows.
4. Subscription on RDS. Create the subscription with create_slot=false and copy_data=true. RDS supports publications and subscriptions natively; you need the master user, which has rds_superuser.
5. Watch it. Check pg_stat_replication on Supabase. An unread slot keeps WAL around and fills the disk, so drop the slot if you abandon the attempt.

Four rules from the PostgreSQL docs catch people. Schema changes aren't replicated, so freeze migrations until cutover. Sequences aren't replicated, so at cutover run setval on every sequence on RDS, or the first insert fails with a duplicate key. Large objects aren't replicated at all. And a table without a primary key, once it's in a publication that replicates updates and deletes, rejects UPDATE and DELETE on Supabase itself, in production. Find those tables in step 1 and give them a primary key, or a replica identity, before you create the publication.

Rehearse either option at least twice against a fresh copy and time every stage. Fix the errors here, not on the night. The usual ones are extensions missing on RDS, grants to roles RDS doesn't have (anon, authenticated, service_role), and objects owned by supabase_admin.

Keeping Supabase Auth, hosted or self-run, changes nothing for your users and is usually cheaper. Cognito costs more per active user once you pass its free 10,000 MAU. Three choices, in order of effort.

• Keep hosted Supabase Auth. Users sign in as before. Your API on AWS verifies access tokens against https://<project>.supabase.co/auth/v1/.well-known/jwks.json, which works when the project uses asymmetric signing keys. You keep paying the Supabase plan and the MAU line.
• Run Supabase Auth yourself. It's an MIT-licensed Go server that takes a Postgres connection string, so it runs on Fargate against RDS. User records and password hashes carry over with the auth schema; plan for existing sessions to end unless you move the signing keys too. The README is blunt that running an auth server in production is hard; you own security updates, SMTP (Amazon SES works) and a TLS proxy in front.
• Move to Amazon Cognito. Supabase stores passwords as bcrypt hashes in auth.users.encrypted_password, and Cognito's CSV import now accepts bcrypt hashes, with a maximum cost factor of 12. Imported users sign in with their existing passwords. OAuth-only users have no hash; social identities live in auth.identities. The alternative is Cognito's migrate-user Lambda trigger, which checks each password against the old store at first sign-in.

Check the cost factor in your own hashes (the number after $2a$) before you plan the Cognito route, and test a sample import first. Users imported with hashes must use USER_PASSWORD_AUTH until their first sign-in, not SRP, so your client code may change.

Run the official Docker Compose stack on one EC2 instance: about $108 a month for the machine, disk and IP address, before backups, failover and the time to run it. It's the middle path between hosted Supabase and AWS-native.

Supabase's supported way to self-host is Docker Compose. The guide asks for 4 GB of RAM, 2 cores and 40 GB of SSD as a minimum, and recommends 8 GB or more, 4 cores and 80 GB.

The machine is cheap. The work isn't. Supabase's page says that when you self-host you're responsible for server maintenance, security hardening and updates, Postgres maintenance, high availability, backups and disaster recovery, and monitoring. Branching, managed backups and PITR, the Management API and multiple projects aren't available. Updates arrive as Compose snapshots roughly monthly, and mixing image versions isn't guaranteed to work.

Our view: self-hosting the whole stack on one VM swaps a $25 to $600 Supabase bill for a single machine nobody is paged for. It's reasonable for internal tools. For a product with customers, take the database to RDS and self-run only the pieces you need (usually PostgREST and Auth) as Fargate services. The official stack ships its own Postgres image with Supabase's extensions, so pointing it at RDS needs testing before you plan around it.

Moving Auth to Cognito, Realtime, many Edge Functions or a mobile app with old versions in the field push it toward six weeks; the quote says which. Everything is Terraform in your repository, in your AWS accounts. If you'd rather not run it afterwards either, our managed DevOps plans pick up from cutover day, and fractional DevOps starts at $2,900 a month.

When you don't need us: a small Pro bill, a team of two, no compliance asks. Stay on Supabase, and come back when one of those changes. If you aren't sure, the AWS readiness review prices both sides for your actual app before you commit to anything.