Migrating From Supabase to Amazon RDS: A Planning Guide

Supabase is Postgres plus services. RDS is Postgres only. List each service you use and decide its replacement:

• Auth: user records in the auth schema, sessions and providers need a new identity system, and password hashes need a plan for import.
• Auto-generated APIs: if clients call the database through the generated REST layer, you'll need your own API or another layer.
• Row-level security: policies that use Supabase's auth functions need a different way to know the current user, such as session settings your API sets per request.
• Storage: files in Supabase storage move to an object store, with URLs and access rules rewritten.
• Realtime and edge functions: each needs a replacement, such as your own websocket layer or serverless functions.
• Extensions: confirm every extension you use, including any vector search extension, is supported on RDS at your Postgres version.

If the answer is that you rely on most of these, ask honestly whether moving is worth it. The comparison in MongoDB Atlas vs AWS RDS vs Supabase and Supabase vs AWS RDS for software development companies helps frame that.

Do the groundwork before copying data:

1. Choose an RDS Postgres version at or above your current one and check extension support against your list.
2. Create the instance in private subnets, with encryption, backups and Multi-AZ decided by your recovery targets.
3. Recreate roles and grants. Dumps of one database don't include cluster-wide roles, and Supabase-specific roles won't exist.
4. Decide connection handling. Supabase provides pooling; on RDS you may add a proxy or pooler for many short-lived connections.
5. Exclude Supabase-managed schemas from the migration unless you have a reason to bring them, and move only your application schemas.

Size the instance from real metrics rather than guesses; the managed Postgres cost comparison shows how to price the options.

For a database of modest size, dump and restore is simplest: run pg_dump for your application schemas, restore into RDS with pg_restore, then rebuild indexes and run analyze. Time a rehearsal with a real copy. The result tells you how long the maintenance window must be.

If the window is too long, look at logical replication, which streams changes from the old database to the new one until cutover. Whether it's available depends on your Supabase configuration and permissions, so check the current documentation and test it. After copying, verify: row counts on every table, checksums on critical ones, sequences set past the max ID, and constraints and triggers present. Run your application test suite against the new database.

Write the runbook and rehearse it:

• Announce the window, and put the app in maintenance or read-only mode.
• Stop writes on the old database, and wait for replication or take the final dump.
• Restore or promote on RDS, verify counts, and reset sequences.
• Switch connection strings and secrets, and restart services.
• Run smoke tests: sign in, create a record, run a background job.
• Monitor errors and latency, and keep the old database read-only and intact as a fallback.

Decide the rollback trigger and who owns it before you begin. Rolling back after new writes on RDS is harder, so the fallback window is mostly for the first hours.

Set up what Supabase used to provide. Turn on automated backups and test a restore into a scratch instance, add monitoring and alerts on CPU, storage, connections and replication, and document how migrations are applied. Review how you'll patch minor versions and plan for major upgrades. Watch cost for a month, including data transfer and storage growth. Your delivery process may also change; DORA's 2024 report describes lead time for changes from under one day to one to six months across its clusters¹, so measure yours before and after to see whether the new setup slowed releases. Related move steps are in the Heroku to ECS checklist.