Your Supabase free-tier database has no backups. Here is how I fixed that in 15 minutes.

Siddhartha Kodali — Thu, 17 Sep 2026 16:04:38 +0000

The gap

Supabase Pro takes a daily backup and keeps it for seven days. The free tier does not take any. That is a fair deal for free hosting, but a lot of side projects that end up with real users started on the free tier, and the backup question never came up again.

There is a second problem that applies to Pro as well: the backup lives inside the same platform as the database. If your account is locked, if there is a regional outage, or if you decide to move to Neon or to your own server, a backup you cannot download is not one you can restore anywhere else.

The fix has been the same for twenty years: run pg_dump on a schedule and write the file somewhere you control. What usually gets skipped is the part around it. You want an alert when the job silently stops running, a check that the file will actually restore, and retention that never deletes the wrong file.

I built Dumpling to do that and nothing else. Here is the full setup for a Supabase project. It took me about fifteen minutes the first time.

Step 1: create a read-only database user

Don't give a backup service your postgres superuser. In the Supabase SQL editor, run:

CREATE ROLE dumpling LOGIN PASSWORD 'a-long-random-password';
GRANT CONNECT ON DATABASE postgres TO dumpling;
GRANT USAGE ON SCHEMA public TO dumpling;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dumpling;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO dumpling;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO dumpling;

Repeat the three GRANT lines for any other schema you want included. pg_dump only needs SELECT. If you ever want to cut the service off, DROP ROLE dumpling is enough, and the worst outcome is a failed-backup email.

For the connection details, open Project Settings, then Database, then Connect, and choose the session pooler: host aws-0-<region>.pooler.supabase.com, port 5432, user postgres.<project-ref>. Avoid the direct db.<ref>.supabase.co host, which is IPv6-only unless you pay for the IPv4 add-on, and avoid the transaction pooler on port 6543, which cannot run pg_dump.

Step 2: create a bucket you own

Any S3-compatible bucket works: S3, Backblaze B2, Wasabi, DigitalOcean Spaces, Hetzner, MinIO. For a first bucket I recommend Cloudflare R2, because the first 10 GB per month are free and there are no egress fees, so downloading a backup to restore it costs nothing.

In the Cloudflare dashboard, open R2 Object Storage and click Create bucket. Name it something like db-backups and leave the location on Automatic.
Open Manage R2 API Tokens and click Create API Token. Set the permission to Object Read & Write and restrict it to the db-backups bucket only. Copy the Access Key ID, the Secret Access Key, and the endpoint, which looks like https://<account-id>.r2.cloudflarestorage.com. The secret is shown once.

Restricting the token to one bucket matters. If the key ever leaks, only that bucket is exposed.

Step 3: schedule the backup

In Dumpling, add the database first: host, port, database name, and the read-only user. The connection is tested before it saves. Then add the storage: endpoint, bucket, and the two keys. It writes and then deletes a small marker object to confirm the token works. Finally, create a job that links the two and choose a schedule. The free plan gives you one job with daily runs.

If you set a passphrase on the job, every file is encrypted with openssl enc -aes-256-cbc -pbkdf2 before it leaves the worker, so you can decrypt it with standard openssl and nothing else.

If your database has an IP allow-list, there is one address to add, and it is listed on the docs page.

Click Run now and watch the log.

Why a successful exit code is not enough

Most backup cron jobs, and a fair number of backup products, report success when the dump command exited with 0 and the upload finished. A dump can exit 0 and still be unusable: a custom-format archive with a missing table of contents, a mysqldump that lost its connection midway and wrote a truncated file, or an empty dump because the user could not see any tables.

Dumpling verifies every run before it counts as a backup. For Postgres, the dump is passed through pg_restore --list while it is being uploaded. If pg_restore cannot read the archive's table of contents, the run is recorded as a failure. For MySQL, the stream is checked for the -- Dump completed trailer that mysqldump writes last. The run log shows the result:

Verified: 142 tables with data, 96 indexes, 611 entries

That line is the difference between "a file exists in the bucket" and "this file restores".

The restore command is shown next to every run, so you are not searching for the right flags during an incident:

createdb restored_db
pg_restore --no-owner --no-acl -d restored_db 2026-09-17T02-18-00Z.dump

Run a restore drill

A backup is only proven when you restore it. I did this with my own service this week. I took the off-site copy of Dumpling's own database, brought the app up from it on a laptop, and checked that the stored secrets decrypted with the key from my password manager.

It took ten minutes and thirteen seconds from file to running server. The drill also found a bug in my restore procedure: a Docker volume directory was owned by root after the copy, so SQLite could not write to it. The code was fine, the written procedure was not. That is exactly what drills are for, and I would suggest running one on your own project before you need it.

For a Supabase project, the drill is the two commands above against a local Postgres, a row count on your largest table, and dropdb restored_db. It takes about fifteen minutes, and once a quarter is plenty.

DEV Community: Siddhartha Kodali