How to Export Lovable Auth Users to Your Own Supabase

Why can't I export my auth users the same way I export my tables?

Because the Supabase CLI's standard db dump intentionally excludes the auth schema. Supabase's own reference states the command "ignores" the auth, storage, and extension-created schemas, so a plain supabase db dump --schema public gives you every table except your users. That single default is why teams wrongly conclude auth data can never move and fall back to a full password reset.

Your public-schema rows (profiles, orders, settings) come across cleanly with the ordinary dump used in a normal Supabase migration. The users themselves — email, identities, and the hashed password each person signs in with — live in the auth schema managed by the GoTrue auth server, and that schema is filtered out unless you ask for it explicitly.

The distinction matters because keeping the hashes means nobody has to reset a password on cutover. Lose them and every user is locked out until they click a reset email — a worse experience and a measurable drop-off.

Related: The general Lovable-to-your-own-Supabase migration · What a Supabase edge function is

Do the password hashes actually come across, or do users have to reset?

They come across — if you can reach the source database. GoTrue stores each password as a hash inside the auth schema, and Supabase's documented project-to-project migration dumps the full schema, auth included. Restore that dump into your new project and every user signs in with the same password. The reset campaign is only the fallback for when you cannot get a database connection at all.

This is the single reason to do the export properly rather than the easy way. A reset email to your whole user base costs you activations; a clean auth-schema restore costs your users nothing and they never notice the move.

The trade-off: dumping auth requires a real database connection string with the Postgres password, not just the anon key that ships in your frontend. The rest of this guide is about getting that connection and running the right dump.

Related: Why exported apps lock users out on cutover

What connection string do I need to reach the Lovable-provisioned database?

You need the database connection string with the Postgres password — found under Project Settings, Database in the Supabase dashboard for the project Lovable provisioned. The anon and publishable keys baked into your app cannot dump auth. This is the step where you must genuinely own or claim the underlying Supabase project, because without database-level access there is no way to read the auth schema.

Supabase exposes two connection strings that work for a dump: the session pooler (port 5432, IPv4-friendly) and a direct connection. Copy the exact string from the dashboard rather than hand-building it — the host and username formats differ between the pooler and a direct connection.

A session-pooler string looks like postgresql://postgres.[PROJECT-REF]:[PASSWORD]@aws-0-[region].pooler.supabase.com:5432/postgres. Store it in an env var (export SRC="...") so it never lands in your shell history in plaintext.

Related: Move secrets out of the client bundle

What is the exact command sequence to export the auth users?

Use Supabase's documented backup flow, which captures roles, the full schema (auth included), and data as three files. Run each supabase db dump against the source connection string you exported as SRC. This is the same sequence Supabase publishes for moving a project between Supabase organisations — it is not a Lovable-specific hack, which is why it is safe to run on a live database.

If you only want the users and nothing else, pg_dump the auth schema on its own instead: pg_dump "$SRC" -n auth --no-owner -f auth_only.sql. The -n flag selects a single schema and all its objects, and --no-owner drops ownership statements so the restore does not fail on roles that do not exist in the target.

1. Install the CLI if you have not already: npm install -g supabase (then supabase --version to confirm).
2. Export the source connection string once: export SRC="postgresql://postgres.[REF]:[PASSWORD]@aws-0-[region].pooler.supabase.com:5432/postgres".
3. Dump roles: supabase db dump --db-url "$SRC" -f roles.sql --role-only
4. Dump the full schema (this is the step that includes auth): supabase db dump --db-url "$SRC" -f schema.sql
5. Dump the data: supabase db dump --db-url "$SRC" -f data.sql --use-copy --data-only
6. Sanity-check the schema file actually contains your users: grep -c "auth.users" schema.sql should return a non-zero count before you go further.

How do I restore the auth users into my new Supabase project?

Create the destination project first, grab its connection string, then replay the three dump files in one psql transaction. Order matters: roles, then schema, then data, with replication role set to replica so foreign-key and trigger checks do not reject the auth rows mid-restore. Running it as a single transaction means a failure rolls the whole thing back cleanly rather than leaving half your users imported.

1. Create a new project at supabase.com and copy its connection string into a second env var: export DST="postgresql://postgres.[NEW-REF]:[PASSWORD]@aws-0-[region].pooler.supabase.com:5432/postgres".
2. Restore all three files in one command: psql --single-transaction --variable ON_ERROR_STOP=1 --file roles.sql --file schema.sql --command 'SET session_replication_role = replica' --file data.sql --dbname "$DST"
3. Confirm the users landed: connect with psql "$DST" and run select count(*) from auth.users; — the count must match the source project.
4. Point your app's env vars (VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY) at the new project.
5. Test a real login on a throwaway deploy URL with an existing account and its original password — success means the hashes restored correctly.

Which export method should I use, and what if I can't reach the database?

Pick by how much access you have and how much downtime you can absorb. If you hold the database password, the full backup-restore keeps every password. If you only have the auth schema to move, raw pg_dump is leaner. If you cannot get database credentials at all, the password-reset campaign is the honest fallback — slower for users, but the only path without a connection string.

The reset campaign is covered in the main migration guide: trigger it after DNS cutover, not before, so the reset link points at the new app. It works, but it converts a silent, invisible migration into a visible one — which is exactly what the auth-schema dump avoids.

Related: Full order of operations for leaving Lovable · Hand the whole migration to an engineer