Backups [database & storage] without supabase-cli

[ethicnology]

Database backups are well documented, but since the project evolve over time, postgres user cannot be a superuser anymore, which generate errors while restoring backups using standard tools such as pg_dump, pg_restore and psql.

1. How to deal with these errors related to constrained postgres user ?
2. If you back up only public schema, how do you deal with triggers for new_profile on auth or even storage related stuff ?
3. How to back up storage data + policies ?
4. How to restore all this information in a fresh supabase project ?

CONSTRAINT: the solution must work in hosted and self-hosted environment

Database

Backup

pg_dump -h xxxxx.pooler.supabase.com -p 5432 -d postgres -U postgres.xxxxx --schema-only > backup.sql

Restore

psql -h xxxxx.pooler.supabase.com -p 5432 -d postgres -U postgres.xxxxx < backup.sql

[tristdrum]

Would love to know the answer too

[djshubs]

Same here. I would like to know what are the steps to do backup and restore.

[theranajayant]

Same here. Reading 3rd thread, no answer for this.

[ethicnology]

@kiwicopple Could we have your opinion on the topic?

[ethicnology]

@theranajayant @tristdrum @djshubs @neiled

This is my procedure to backup supabase instance with classic tools.
I'm using only auth + postgres + storage in supabase, no other features will be covered.

1. Backup all schema using psql / pg_dump. The most import schema (IMO) are: auth,public,storage

• auth (contains your users)
• public (contains your data)
• storage (contains your buckets and links to objects)

2. Export all buckets using rclone sync (you have to rclone config before)

The re-import process is the opposite, using psql / pg_restore, it works well with data but, you could be blocked for schema as supabase protect superuser role. You can also re-upload all buckets you saved using rclone or the Studio.

I'm sharing with you the script I'm using to backup schemas. You can select which schema you want to include in your backup but also specify if you want --schema-only or --data-only. You can give it a try:

You can set up environment variables (export DB_PASS='mysecretpassword') or pass the params, as follows:

./pg_backup.sh --DB_HOST=<region>.pooler.supabase.com --DB_PORT=6543 --DB_NAME=postgres --DB_USER=postgres.<id> --DIR=./backup

Gist to the script

If you have any tips, please share

[igorlanko]

Could you share your rclone config? I'm constantly getting:

https response error StatusCode: 403, RequestID: , HostID: , api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.

when trying any operations with Supabase Storage via S3 config in rclone config.

[baptiste-mnh]

Same here, it works for me with boto3 or the AWS CLI.
Probably something wrong with the rclone config ?

[supabase]
type = s3
provider = Other
region = eu-central-1
access_key_id = XXXXXXXXXXXXXX
secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXX
endpoint = https://xxxxxxxxxxxxxxx.supabase.co/storage/v1/s3
signature_version = 4

[Schotsl]

Same for me, has anybody found the solution?

[lautaroPH]

I had the same error and when I change the version of rclone to 1.62 for windows it works normally for me. Hope that this help someone

[Schotsl]

The issue arises when using any version above v1.67.0. Starting from v1.68.0, the AWS SDK v1 was deprecated and replaced with v2. It seems that Supabase is still operating on v1 and does not yet support v2. The only workaround I’m aware of is to revert to the earlier version.

[highway11]

After many hours of struggling, I finally have a working backup and restore system for my self hosted Supabase. There were several roadblocks that took awhile to find the solutions for:

1. you need to login to the database as user 'supabase-admin.your-tenant-id' instead of 'postgres'
2. you need to connect to template0 database in order to drop the postgres database, then recreate it before restoring

Here are the scripts that backup and restore supabase fully, including all schemas. The only thing missing would be moving your actual storage files if you are using storage

This script expects you to have postgresql-client tools installed on your docker host

https://gist.github.com/highway11/747c45e8fb6c8df73f562e859801dd2d

You may still see a couple of errors on the restore procedure, but I think these are inconsequential and all the data is there

[supertj]

The accepted answer is still the right blueprint. A few additions for people landing here from search in 2026 — these are the things that bit people later in this thread, plus what I'd add after running this setup in production:

1. The rclone signature errors reported above (@igorlanko, @Schotsl). Versions after 1.67.0 (reports in this thread start at 1.68.0) had trouble against Supabase's S3 endpoint, while pinning an older release like 1.62 (as @lautaroPH suggested) worked. If you'd rather not pin rclone, the plain AWS CLI/SDK talks to the endpoint fine — that's what I ended up using:

aws s3 sync s3://<your-bucket> ./storage-backup/<your-bucket> \
  --endpoint-url "https://<project-ref>.storage.supabase.co/storage/v1/s3" \
  --region <project-region>

Credentials come from Dashboard → Storage → Settings → S3 Access Keys. Note these keys bypass RLS — treat them like a service-role key and keep them out of client code.

2. Match your pg_dump major version to the server. Supabase currently runs Postgres 15–17 depending on when your project was created. A pg_dump older than the server's major version can fail (or silently mis-handle newer features). Check with pg_dump --version vs. select version();. On macOS, brew install libpq gets you a current one; on Debian/Ubuntu use the PGDG apt repo for postgresql-client-17.

3. Use the Session Pooler connection string (Project Settings → Database → Connection string → Session pooler), not the direct db.<ref> host — the pooler is IPv4-reachable, which matters from CI runners and most home networks. The default postgres user owns your tables, so the dump passes RLS; a least-privilege dump role is mostly not viable on Supabase because pg_dump errors on any RLS-enabled table the role can't bypass, and bypassrls can't be granted without superuser.

4. A backup you've never restored is a guess. The cheapest verification is restoring into a throwaway Postgres and spot-checking row counts:

docker run --rm -d --name restore-test -e POSTGRES_PASSWORD=test -p 5433:5432 postgres:17
pg_restore --clean --if-exists --no-owner \
  --dbname "postgresql://postgres:test@localhost:5433/postgres" dump.pgcustom
psql "postgresql://postgres:test@localhost:5433/postgres" \
  -c "select relname, n_live_tup from pg_stat_user_tables order by 2 desc limit 10;"
docker rm -f restore-test

If your schema uses extensions (e.g. vector), install them in the container before restoring, or the restore fails.

5. Budget for egress. Every dump + file download counts as uncached egress on your Supabase bill ($0.09/GB past your plan's allowance; the Free plan's 5 GB/month allowance is enforced through a fair-use flow — notice, then a grace period, then restrictions, never a charge — so recurring large backups aren't viable on Free). Weekly is usually the sane default once your data is tens of GB.

Full disclosure: I'm the author of an open-source CLI that grew out of exactly the problems in this thread. npx backupdrill backup streams the dump — and, pointed at your project's Storage S3 keys, the Storage files too — to your own S3/R2 bucket with a SHA-256 manifest, and backupdrill drill does step 4 automatically (throwaway Docker Postgres, extension pre-install, file checksums): https://github.com/backupdrill/cli (MIT). It dumps the schemas you point it at (public by default); for the auth schema specifics, the accepted answer's per-schema pg_dump approach is still what I'd follow.

Longer write-ups of the manual approach: https://backupdrill.com/guides/supabase-backup and, for the restore-verification step, https://backupdrill.com/guides/test-supabase-backup-restore