Supabase
Ready, run with you
- Data
- Postgres to Postgres. We read a pg_dump, load an empty project in one transaction and verify every row count. Tested on a self-hosted Supabase; a Supabase cloud project is the same dump, and we will say when we have done one.
- Users
- Imported with their accounts. GoTrue’s bcrypt hashes verify as they are and are upgraded to our own hashing the first time someone signs in, so nobody has to reset. Password reset is there too, if you prefer a clean start.
- Your code
- The query builder, auth calls and row-level security have the same shape: the import and the key change. Edge functions run on Workers unchanged, through compatibility shims. Cron jobs and the database webhook come across switched off.
- Files
- Bucket records come across. Moving the files themselves is a separate step we do with you.
- Not yet
- A self-service import button. The importer is run by us, alongside you. The first app moved this way is described on the customers page.
Appwrite
Planned
- Data
- Collections and attributes map onto tables and columns cleanly enough. The real work is Appwrite’s permission model: per-document access rules, not SQL. An importer has to translate them into row-level security policies and say plainly where it could not.
- Users
- Appwrite hashes with Argon2id by default, which is what we use, so passwords may import directly.
- Your code
- The SDK calls change; the shapes are close enough to be a mechanical rewrite.
- Where it stands
- Next after Supabase has been proved on more real apps. If you are on Appwrite and want to be the one that shapes it, tell us.
Firebase
Planned
- Data
- Firestore is schemaless documents with subcollections. There is no schema to move, only one to infer, with choices about how to flatten. We can suggest a schema and show those choices; you decide.
- Users
- Firebase uses a modified scrypt, and exporting it needs your project’s signer key and salt separator. Possible; it is a separate piece of work. Storage objects can be moved too.
- Your code
- The queries in your app are rewritten, not repointed, and Cloud Functions are Node, not Deno, so those are rewritten too.
- Where it stands
- This is an assisted rewrite, and we will never call it one-click. It comes after Appwrite.
AWS Amplify
Not started
- Data
- Amplify apps usually sit on DynamoDB through AppSync, with a GraphQL schema on top. A document store to a relational one is a design exercise, much like Firebase.
- Users
- Amplify auth is Cognito, which does not hand out password hashes. Expect your users to reset, which is why the reset flow matters. Their files live in S3, and S3 is a standard API we speak.
- Your code
- Treat it as a rewrite of the data layer, with the rest of your front end kept.
- Where it stands
- We have not started and have not tested this against a real Amplify app, so take the above as our reading, not a promise. If you are on Amplify, tell us: it moves it up the list.
Any Postgres
By hand today
- Data
- Your project is standard Postgres. A
pg_dump from RDS, Neon, a server of your own, or anywhere else restores into it with the connection string in Settings → Database. What the importer automates is the Supabase-specific parts, so on other sources you do the restore by hand, and we will help.
- Users
- If your users live in your own tables, they come with the rest. Add AffinEQ Authentication for new sign-ins and migrate accounts across with a script.
- Your code
- Anything that speaks Postgres keeps working. The REST API, row-level security and the SDK are additions, not requirements.