Migrating from Supabase
Keep Supabase or switch to PocketBase
Ask your agent
Plan how to move my Supabase app to Percher. Inventory its database, auth, storage, functions, and secrets first; keep the existing app working until I approve the cutover.Read the guide at percher.app/docs/migrate-supabase
Keep my Supabase, but host the app on Percher.Read the guide at percher.app/docs/migrate-supabase
How it works, with exact details
Two options: keep using your Supabase project as an external database, or switch to Percher's managed PocketBase. For most apps — and anything that leans on Postgres features — Option 1 is the right call.
Option 1: Keep Supabase
Your data and Supabase services stay at Supabase. Match the environment-variable names your app reads, check the HTTPS connection method, and update authentication redirects. Follow the connection guide before publishing.
Option 2: Switch to PocketBase
Percher generates most of the migration for you. It writes a ./migration-preview/ folder — nothing touches your data until you run the scripts yourself.
Honest limits — read before committing
- Auth users can't be moved directly. Supabase password hashes aren't compatible with PocketBase — every user has to reset their password.
- It's a preview plus a script, not one click. You run the data-import yourself with a Supabase service-role key and review the flagged items.
- Some things don't port at all: Edge Functions, Postgres views/triggers/functions, complex RLS (the tool translates the simple
auth.uid() = columncase and flags the rest), realtime, PostGIS, and pgvector. If your app depends on these, keep Supabase (Option 1).