Staging a Supabase Database Migration

Definition

A staged BaaS migration separates application access, PostgreSQL data and attached services so each boundary can be changed and checked without one all-at-once cutover.

Perspectives

Bear_DBA (@bear_dba) (2026-08-28, Threads)

First stop calling PostgREST directly by putting a backend API in front of the existing Supabase database. Next move PostgreSQL with pg_dump and pg_restore to RDS, Cloud SQL or another target and change the backend connection string. Replace Auth, Storage, Realtime and Edge Functions only after the database move, using parallel reads and writes between the first two stages to check consistency before cutover.

Inventory auth.users, password-hash compatibility, storage.objects, underlying object files, RLS policies and Supabase-specific settings such as pg_net and pg_cron. Reimplement authorization at the application layer where the migration removes RLS behavior, and do not assume PostgreSQL portability also covers the surrounding services.

How to apply

• Start only after Deciding When to Leave Supabase shows both a control need and an operator who can own backups, monitoring, patches and incidents.
• Keep the API boundary stable while moving the database; this reduces simultaneous changes in clients, data and authentication.
• Define reconciliation checks, rollback conditions and an end date before dual operation so temporary parallel writes do not become permanent complexity.
• If the product is still in a speed-first MVP phase, compare the migration burden with remaining on Firebase or Supabase.

Limits

• The thread provides an ordering, not tested commands, downtime estimates, rollback procedures or a schema-by-schema migration runbook.
• Dual writes can create consistency failure modes that the source does not specify how to resolve.
• RDS, Cloud SQL, Auth0, Clerk, S3 and CloudFront are named as destinations without representative URLs or source-backed comparisons, so no separate tool pages were created.

Original link