Migrate from Supabase to Swyftstack in three clicks.
Paste your Supabase connection string. We do the rest. Your source database is never touched.
Why people leave Supabase
- The bill is harder to predict as the product expands
- The dashboard is getting slower as features pile up
- They want PostgreSQL without the platform layered on top
- They use their own auth (NextAuth, Clerk, Auth0)
- They want fewer moving parts
What Swyftstack ships instead
- Flat $19/mo Launch and $99/mo Growth
- Instant dashboard with masked connection strings
- Bring your own auth, no Supabase Auth lock-in
- Daily encrypted backups + one-click restore
- Three-click migration in, with checksum verification
Supabase Pro vs Swyftstack Launch
Feature | Supabase Pro | Swyftstack Launch | |
|---|---|---|---|
| Monthly price | $25 | $19 | |
| Database storage | 8 GB | 10 GB | |
| Object storage | 100 GB | 100 GB | |
| Egress included | 250 GB | 500 GB | |
| Daily backups | |||
| Annual discount | Limited | 21% off | |
| Auth service | Bring your own |
Four steps. Most of them take seconds.
Supabase dashboard → Project Settings → Database → Connection string (URI format). Copy the full URI.
Swyftstack dashboard → Migrate → "From Supabase". Paste, click Start.
Usually 2-5 minutes for projects under 5 GB. Larger databases scale with size.
Swap in the new connection string and redeploy. Your old Supabase project is untouched until you decide to delete it.
Everything Postgres
Tables, indexes, constraints, foreign keys, sequences - byte-for-byte verified.
uuid-ossp, pgcrypto, pg_trgm, citext, PostGIS, pgvector - all preserved.
We can copy them, or skip them if you're moving to app-level authorization. Your call.
The four things to get right
Dump from the direct connection, not the pooler
Supabase gives you a Supavisor pooler (port 6543) and a direct connection (port 5432). pg_dump relies on session state and prepared statements, which transaction-mode poolers break, so use the direct URI from Project Settings, Database.
The public schema is the easy part
Tables, indexes, constraints, sequences, views, and functions restore cleanly onto PostgreSQL 16, with row counts verified both sides. Common extensions (uuid-ossp, pgcrypto, pg_trgm, citext, PostGIS, pgvector) are recreated so defaults and index types keep working.
Auth and RLS are the real decision
Keep Supabase Auth and repoint it at the new database, or move to NextAuth, Clerk, or Auth0. RLS policies that call auth.uid() keep working only if you keep Supabase Auth; move auth and each one needs rewriting against the new user IDs. We list exactly which policies reference those helpers.
Cut over in order, flip last
Migrate the database, verify on a staging copy, repoint or move auth, export and re-upload Storage files (not yet automated), then flip DATABASE_URL in a quiet window. Supabase keeps serving the whole time, so a bad step costs nothing.
Frequently asked
What about Supabase Auth users?
Auth is a separate Supabase service. Keep Supabase Auth pointed at your Swyftstack connection string (it works), or move to NextAuth, Clerk, or Auth0.
What about Supabase Storage files?
Storage migration is not automated yet. Export the files and upload them through the Swyftstack console/API until the full storage gateway ships.
Will my app go down?
Only for the seconds it takes to swap DATABASE_URL and restart your app.
Can I roll back?
Yes. Your Supabase database is untouched. Until you change DATABASE_URL, your old database is still serving traffic.