Switch from Supabase

If you use Supabase for auth, storage, edge functions, and realtime as well as the database, moving to CapyDB means replacing four products, not one. That can be the right call - it usually is when the app has outgrown the coupling - but it is a project, not an afternoon.

If you use Supabase mainly as hosted Postgres and the rest is incidental, this is a straightforward migration and the rest of this page is for you.

• -Your schema, data, indexes, constraints, functions, and triggers
• -Extensions, through the catalog you enable per cell
• -Your migrations, whatever tool produced them
• -Every client library, because the connection string is a normal postgres:// URL

Supabase's row-level security policies are written against its auth schema and its JWT claim helpers. Those do not exist outside Supabase, so a straight dump-and-restore leaves you with policies that reference functions that are not there.

The CLI converts them. The converter is open source, rewrites the policies against vanilla PostgreSQL session settings, and reports anything it could not translate rather than emitting something that silently permits too much.

capydb migrate rls ./supabase --out capyrls

• -Auth: move to a dedicated identity provider, then set the same claims into the session settings your converted policies read
• -Storage: object storage plus signed URLs; the codemod maps bucket semantics for the common cases and flags the rest
• -Edge functions: whatever your deployment platform already runs - these are ordinary serverless functions
• -Realtime: PostgreSQL logical replication and LISTEN/NOTIFY are both available on a cell
• -The database itself: this is the part that is genuinely a lift-and-shift

Import directly from your Supabase connection string. The importer knows about the platform schemas that should not travel and filters them, so you end up with your data rather than with a copy of someone else's control plane.

capydb import \
  --project my-app \
  --source-url "$SUPABASE_DATABASE_URL" \
  --follow

• -Import with follow, and run your test suite against the cell while the source is still live
• -Apply the converted policies and test them with a real session, not with a superuser connection
• -Run capydb doctor for environment variables still pointing at the old project
• -Swap connection strings per environment, watch the logs, then stop the follow
• -Keep the source around, read-only, for a week - it costs little and it has saved people

Tell us before a production cutover. We will review the plan, be around for the window, and keep a restore path ready.