Exporting your data

You can download a full copy of any project at any time, on every plan: the database as a pg_dump file and the Storage files as a .tar.gz archive. Use exports for your own off-site backups, for moving data elsewhere, or to load production data into a local environment.

Both exports are on Dashboard → your project → Backups, and only the owner can create them.

Database export (pg_dump)

1. Open the Backups tab and click Create pg_dump.
2. Wait for the job to finish. Large databases take longer; the job is stopped if it runs for more than 2 hours.
3. Download the file. It's named <project>-<YYYYMMDD-HHMM>.dump, for example app-one-20261111-0930.dump.

The file is made with pg_dump -Fc (Postgres's custom format), which is compressed and lets pg_restore pick individual tables or schemas. It contains the project's whole database: your schemas and data, functions, triggers, RLS policies, the auth schema with users and identities, and the storage schema with bucket settings and object rows.

In a test, a 0.8 GB project's dump was restored into a fresh Supabase Postgres in 29 seconds.

Look inside a dump

# List what's in the file
pg_restore -l app-one-20261111-0930.dump | head -40

Restore into another Postgres

Restore only your own schema into a plain Postgres database:

pg_restore --no-owner --no-privileges --schema=public \
  -d "postgresql://user:[email protected]:5432/bookings" \
  app-one-20261111-0930.dump

--no-owner and --no-privileges skip Supabase role names such as anon and authenticated, which a plain Postgres doesn't have.

Restore into a local Supabase

With the Supabase CLI running locally:

supabase start
pg_restore --no-owner --no-privileges --schema=public \
  -d "postgresql://postgres:[email protected]:54322/postgres" \
  app-one-20261111-0930.dump

This loads your tables and data but not Auth users. If your tables have foreign keys to auth.users, pg_restore reports errors for those constraints, because the users they point at aren't there; the rest still loads. For local work it's often better to keep real user data out of your laptop and create test users instead; see Seeding data.

Storage export (Package files)

1. On the Backups tab, click Package files.
2. Wait for the job, then download <project>-storage-<stamp>.tar.gz.

The archive contains:

Before it starts, the job checks the instance has enough free disk: 1.1 times the size of your files plus 512 MB. If there isn't enough space it won't start. The disk grows automatically as it fills, so space may be available later; if the export still won't start, email [email protected].

Unpack it with:

mkdir app-one-files && tar -xzf app-one-storage-20261111-0930.tar.gz -C app-one-files

Storage files aren't in the daily database backups, so this export is the way to keep your own copy of them. See Backups.

Download links

Download links look like https://acme.supahost.space/exports/<40 hex characters>/<file> and last 24 hours. The long random part of the URL is what protects the file, so treat the link like a password: don't paste it into public chats or tickets. After 24 hours, create a new export.

From a terminal:

curl -fLo app-one-20261111-0930.dump \
  "https://acme.supahost.space/exports/<token>/app-one-20261111-0930.dump"

Other ways to get data out

• Studio can export a table as CSV from the table editor.
• The Data API can page through any table your key can read.
• SSH and the tunnel (Business and Enterprise) let you run pg_dump and psql yourself; see SSH access and direct Postgres.

Related

• Backups
• Moving off SupaHost
• pg_dump fails with "query would be affected by row-level security policy"