Migrate from Supabase

Get the source connection string

In the Supabase dashboard: Project → Connect (top bar). You will see three flavors — pick carefully:

• Direct connection (db.<ref>.supabase.co:5432) — best for imports, but it is IPv6-only on most projects unless the IPv4 add-on is enabled.
• Session pooler (aws-0-<region>.pooler.supabase.com:5432) — IPv4-reachable and fine for an import (it behaves like a session-mode connection).
• Transaction pooler (port 6543) — avoid for imports.

Practical rule: use the session pooler URL unless you know your project has IPv4 enabled on the direct host. The username on pooler URLs includes the project ref (postgres.<ref>), which is expected.

Supabase-specific caveats

• You are migrating the database, not the platform. Supabase Auth, Storage, Edge Functions, and Realtime do not come along. The auth, storage, and realtime schemas will be in the dump — decide what your app still needs from them. If you use Clerk, CapyDB's Clerk auth sync covers the user-table-in-your-database pattern.
• Extensions: Supabase enables many by default. The CapyDB allowlist covers pgcrypto, uuid-ossp, pg_trgm, citext, hstore, pg_stat_statements, and vector (pgvector). Sources using postgis, pg_graphql, pgsodium, supabase_vault, etc. will fail the extension preflight — drop them on the source copy first or contact support.
• RLS policies transfer with the schema; they keep working in plain Postgres, but nothing manages them for you anymore.

Preflight

capydb import preflight --source-url "postgres://postgres.<ref>:password@aws-0-eu-central-1.pooler.supabase.com:5432/postgres"

Expect the extension check to be the interesting one. Fix failures before the window, not during.

Import

Pause writers, then:

capydb import --source-url "postgres://..." --recreate --wait

After the import

1. Spot-check sequences on hot tables.
2. \dx — verify the extension set; drop leftover Supabase-specific schemas you decided not to keep.
3. ANALYZE;
4. Cut over DATABASE_URL, deploy, and watch Observability.