Why your Supabase dump has no users in it

You did the responsible thing. You looked up how to back up a Supabase database, ran the command you found, and put the file somewhere safe.

Then one day you need it. You replay the file into a fresh project and the restore finishes without a single error. Every table you ever made is there, and every one of them is empty. Your users are worse off than that: the part of the database they live in, a schema called auth, never reached the file at all.

Here is the part almost every guide skips: supabase db dump on its own is not a copy of your data. With no other flags it writes the shape of your database and none of its contents, and it leaves auth out of even that. Supabase publishes the backup as three commands, and your accounts ride in the third one.

It helps to picture a hotel. Your tables are the rooms and everything in them. The register at the front desk, the one with every guest's name in it, is the hotel's. And a floor plan shows you every room in the building without putting a single guest in one.

Does a Supabase backup include my users?

It depends which command wrote the file, and the command most people run does not.

Your users are not rows in one of your own tables. Supabase keeps them in a separate drawer of the same database called the auth schema, along with their hashed passwords, the providers they signed in with and the sessions they hold. Your own tables sit in a drawer called public, and every user_id column in them is a reference across into auth.

A schema is exactly that: a named drawer inside one database. public is yours. auth is Supabase's, and so is storage, which keeps the row describing each uploaded file. Supabase's own documentation calls these its managed schemas and says they typically do not need to be pulled unless you have modified them, which is why the tooling treats them differently from your tables.

That division is what lets one command produce two files that look alike and hold entirely different things.

What the dump command writes on its own

The floor plan. No rows, and nothing from auth.

Supabase's reference page for the command says it in two sentences. It runs pg_dump with extra flags to exclude the Supabase managed schemas, and the ignored ones include auth, storage and those created by extensions. The same page then says the default dump contains no data and no custom roles, and that you get those by asking for them with --data-only and --role-only.

So this, which is the one you have probably run:

supabase db dump --db-url "postgresql://…your connection string…" -f backup.sql

produces a file of CREATE TABLE statements. Every column, every index, every policy you wrote on your own tables, and not one row of anything.

The reason this is worse than an obviously empty file is that it works. It is not obviously small either: every table definition, index and policy you ever wrote is in there, which for a real app is a lot of text. An empty backup announces itself. This one restores cleanly, and the first thing that tells you otherwise is a login page no account can get past.

How do I check the dump I already have?

Open it in a text editor and search for auth. What comes back puts your file in one of three groups.

1. No matches at all. The auth schema is not in this file in any form. This is what a plain supabase db dump writes.
2. Matches, but only in lines beginning CREATE, ALTER or GRANT. You have the design of the register and nobody in it.
3. A line reading COPY "auth"."users" or COPY auth.users, with rows of data under it before a line containing \. Or a run of lines beginning INSERT INTO "auth"."users". Your accounts are in there.

If you would rather do it at a command line, two greps answer the same question:

grep -c 'auth.*users' backup.sql
grep -n 'COPY .*auth.*users\|INSERT INTO .*auth.*users' backup.sql

The first says whether the schema reached the file at all. The second says whether the people did. A zero from both, on a file you were relying on, is worth finding out today rather than on the morning you need it.

Search for storage while you are in there, and read what you find carefully. Those rows are the list of your uploaded files, which is a different thing from the files, and no database backup on any plan contains those.

How do I export Supabase auth users?

With the data command, which is a separate command from the one that writes the schema.

Supabase's backup and restore guide publishes the backup as three files, and it is worth seeing them together because the shape of it is the answer:

supabase db dump --db-url "postgresql://…" -f roles.sql --role-only
supabase db dump --db-url "postgresql://…" -f schema.sql
supabase db dump --db-url "postgresql://…" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"

The second line is the one that gets run on its own. The third is the one with your users in it.

Those two facts look like a contradiction and they are not. The sentence on Supabase's reference page about excluding auth describes the schema dump, and the data dump walks that schema too.

If all you want is the accounts, name the schema and you get that drawer alone:

supabase db dump --db-url "postgresql://…" -f users.sql --data-only --use-copy --schema auth

Before you rely on any of these, add --dry-run and read what comes back. It prints the pg_dump command the tool is about to run without running it, so you can see for yourself which schemas are included and which are excluded on the version you have installed. Read that output once and you never have to take this article's word for it, or anybody else's, which matters because the flags do move between releases and the file looks the same either way.

There is also the direct route, which is what a plain pg_dump is for: name the drawers you want and it takes them.

pg_dump "postgresql://…" --schema public --schema auth --schema storage \
  --no-owner --file backup.sql

One thing to notice about the schema file, because it explains why this is split up at all. A new Supabase project arrives with an auth schema already built, at whatever version the sign-in service is running today. Replaying your old project's version of that schema over it would put an older design on top of a working one. What you want to carry across is the contents of the register, which is what the data file holds.

What breaks when you put the users back

Two things, and Supabase documents both of them.

Triggers, which can encrypt a column twice. The restore command in Supabase's guide has an instruction in the middle of it that is easy to read as noise:

psql \
  --single-transaction \
  --variable ON_ERROR_STOP=1 \
  --file roles.sql \
  --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "postgresql://…"

That middle line switches triggers off for the duration, and the guide says it is there to stop columns being encrypted a second time on the way in. Replay a data file without it and the passwords arrive already scrambled by a process that had already been applied to them, which nothing later will undo.

Ownership and grants, which will stop the replay. A dump taken from a Supabase project carries lines that refer to roles the new project will not let you touch. Supabase's troubleshooting notes for the same guide say to comment out any line containing ALTER ... OWNER TO "supabase_admin" in schema.sql, and a specific GRANT "postgres" TO "cli_login_postgres" line in roles.sql. Both are a text edit before you start, and both stop the replay with the line they choked on printed on your screen.

Do my users have to log in again?

Their passwords come across. Their sessions do not, unless you carry one more thing with them.

Supabase says you can migrate every table in the auth schema, including users and their hashed passwords, so nobody has to reset a password they already had. No password is readable at any point in this; what moves is the hash of it.

A session is a different thing. It is proved by a token that was signed with your project's own JWT secret, and each project has its own. Supabase says that if the new project signs with a different secret, every token already in someone's browser becomes invalid and they are asked to sign in again. You can avoid that by setting the old project's secret on the new one, and there is a cost written on the same page: changing the JWT secret regenerates that project's anon and service_role keys, so your app has to be given the new ones before it can talk to anything. Which key is which, and which of them is safe to have in your app at all, is the thing to be sure about before you paste either.

So the honest version is that a restore usually asks everyone to sign in once. That is a support email. It is not a lost account, and the difference between those two is whether the auth schema was in your file.

Three things are still not in it, whatever you do with the flags. Your uploaded files, because Storage keeps the bytes outside the database and no dump on any plan reaches them. Your edge functions, which are their own download, and whose import maps Supabase notes are not fetched automatically. And your project's settings, which are configuration rather than data and get re-entered by hand.

What to do this week

Doing this once by hand is worth it however you end up backing things up, because until you have opened a dump you have only ever had the word backup to go on. Whether you keep doing it by hand is a separate question, and the three routes and what each one costs is where that one gets answered.

Where Reeve Care fits

Care takes the copy on a schedule, and the register is in it.

• Your accounts are in the copy. The auth schema travels with your own tables, because a copy of a Supabase app without its users is a copy of half of it. The storage rows that describe your files come too, and so do the files themselves once you connect a Storage credential.
• The restore button puts your tables back and leaves the accounts alone. Replaying auth.users over a live project signs everyone out and brings back accounts somebody deleted on purpose, so that stays a request with a person on it. So pressing the button in a panic cannot log out the customers you were trying to help.
• The copy is read back before it counts as taken. The date on your dashboard is the last time a copy was opened and verified, never the time a job started or a file landed.
• Restoring takes a snapshot of the current state first, so the restore itself has an undo.

Care starts at $49 a month for one app. That is a list price, and the pricing page is sometimes below the figure here and never above it.

How a copy is taken, checked and put back is drawn step by step on the Supabase backups page.

Before you close this tab, open your most recent dump and search it for auth. It is the fastest way to find out whether the thing you have been calling a backup would give you your customers back, and if the answer turns out to be no, restoring one properly is the next thing to read.