Migrate from Supabase without rewriting your app

Short version: the migration tool moves your schema, RLS policies, users, rows, foreign keys and files. Triggers and Edge Functions need manual work, and the report tells you exactly which ones before you commit to anything.

How the migration works

1. Connect. In the dashboard, choose "Migrate from Supabase" and paste your database connection string and service role key.
2. Check compatibility. You get a report with counts of tables, users, storage buckets and functions, plus anything that blocks the move or needs attention afterwards. Nothing is copied yet.
3. Migrate. instancez creates the app, applies the schema and RLS, then copies users, rows and storage files. You can watch each stage, and a failed run can resume where it stopped.
4. Switch the client. Point your app at the new URL and key.

- createClient(SUPABASE_URL, SUPABASE_ANON_KEY)
+ createClient(INSTANCEZ_URL, INSTANCEZ_PUBLISHABLE_KEY)

That's the only client change for features instancez supports. A community clinic moved an 8 GB Supabase instance this way and was back online in under an hour.

What moves automatically

• Schema: Tables and columns, translated into instancez.yaml
• Row-level security: Table policies, translated into the same file
• Users: Same user IDs and password hashes, so people sign in with their existing passwords
• Data: Every row, including auto-increment sequences
• Foreign keys: Every one instancez can recreate exactly, added after the rows are copied
• Storage: Buckets, files and storage policies, as per-bucket rules
• SQL functions: RPC functions with regular arguments, including SECURITY DEFINER ones, and policies that call them

What needs manual work

We'd rather you hear this now than find it after the switch. The compatibility report flags each of these for your project specifically.

• Some foreign keys: Ones instancez would recreate differently are skipped, and the report names each one.
• Triggers: Not copied, including ones on auth.users that create profile rows. Recreate them after the move.
• Edge Functions: Supabase runs them on Deno; instancez runs JavaScript on Node.js. Port them by hand.
• Some SQL functions: Functions with OUT, INOUT or VARIADIC arguments, or that use realtime, vault, cron, net, graphql or pgsodium.
• Auth settings: OAuth provider secrets, email templates and SMTP settings. The report lists what to re-enter.

Features instancez doesn't have yet also stay behind: Realtime subscriptions, phone/SMS login, OAuth providers other than Google and GitHub, branching, the log explorer and point-in-time recovery. If your app relies on Realtime, wait before moving it.

Before you start

• Run the compatibility check first. It's free and doesn't copy anything.
• Keep your Supabase project running until you've tested the new backend.
• Plan a short write freeze for the final run if your app takes writes around the clock.
• Hosted instancez runs in AWS us-east-1. If you need another region, self-host the binary.

Check compatibility for free →

Still deciding? Read how instancez compares to Supabase and Neon.