Why you can't download your Supabase backup

You are on a paid Supabase plan, so you have backups. You open Database, then Backups, and there they are: a list of dated daily copies, each with a Restore button. You go looking for the button that lets you download your Supabase backup and keep it somewhere of your own, and there isn't one.

Nothing is broken. Here is the part older guides still get wrong: on a current project there is no daily backup to download. Supabase moved its daily copies to a different kind of backup, one it can restore for you and cannot hand over. The download button those guides describe belonged to the older kind. A file you hold is something you now make yourself, and it is a different kind of file.

Your phone is the easiest way to picture the difference. The backup it takes of itself every night is complete and exact, and it comes back onto a phone signed into the same account in one step. You cannot open it on a laptop and take your photos out of it. For photos you can keep anywhere, you export them, and what you get is a folder of ordinary files. Supabase's daily backup is now the first kind. The file you can hold is the second.

Can I download my Supabase backup?

Not the daily one, if your project runs Postgres 15.8.1.079 or newer. Supabase's backup documentation says all projects on that version and newer use physical backups, and its troubleshooting notes say that once physical backups are on, Supabase no longer generates the downloadable backup file. You can restore those copies whenever you like. You can't take one with you.

The last row is the one to read twice. Supabase says that when a project is deleted it removes all associated data, including any backups stored in S3. Delete the project and its daily copies go in the same step.

What is the difference between a physical and a logical backup?

Where the copy is taken from. A physical backup copies the files Postgres itself writes to disk, which Supabase describes as a snapshot of the underlying directory of the database. A logical backup asks the database to describe itself in SQL, table by table and row by row, and writes that description to a text file.

Each is good at something different. A physical copy is quick to take and quick to put back, and it comes back exactly as it was. It can only be read by the same kind of Postgres setup it came from, which on Supabase means Supabase's own machines. A logical copy is slower to replay and bulkier to store, and any Postgres of the same version or newer can load it. It is the phone backup and the exported folder again, and only the second is a file you can hold.

The download button people remember was the logical kind. Supabase's own documentation from 2025 said the daily job ran pg_dumpall, zipped the SQL file and stored it, and that physical backups put less load on the database and avoid holding locks on your tables for long periods. The same page said physical copies cannot be downloaded from the Backups section of the dashboard.

How do I tell which one my project has?

Look for a download option on the Backups page. Open Database, then Backups, in your Supabase dashboard. If each dated copy has a way to download it, your project is still on logical backups. If each one offers Restore and nothing else, it is on physical backups, and Supabase's older documentation used exactly that test.

The second check is the version number. It is printed under Project Settings, then General. Anything from 15.8.1.079 upwards means physical backups. Read it left to right: a version starting 17 is newer than any 15, and 15.8.1.100 is newer than 15.8.1.079.

Two cases need no checking at all:

• Point-in-time recovery is on. It runs on physical backups by definition. Supabase also says that if you switch point-in-time recovery off, it keeps taking physical backups, so the download does not come back.
• You are on the free plan. The Backups page has nothing on it to download or restore, because the free plan gives you no daily backups to use. Making a copy without a terminal is the place to start.

What does each one protect me from?

The daily backup protects you from something going wrong inside the project. A file you hold also covers losing the project itself.

The first kind of loss is the one you cause yourself. A delete that caught more rows than you meant, a migration an AI agent wrote and you approved, a script pointed at the wrong table. The daily copy is exactly the tool for that: pick yesterday, press Restore, and the project is put back. How far back it can reach depends on your plan, and which plan you are on settles it in about two minutes.

The second kind does not involve a mistake in the database at all. A card that expired while you were away, a login you cannot recover, a project somebody deleted. The copies are on the far side of the same door as the project, and the door is the thing that closed. Your phone's backup behaves the same way: it rescues you from a phone dropped in the sea, and it is no help on the day you cannot sign in to the account it lives in. Supabase keeps its backups with the platform because that is what lets a restore take one button. A copy that survives the account has to be stored somewhere else, which on Supabase means a logical dump taken out of it.

What does restore mean for each one?

For the daily copy, Supabase does the work and you choose where it lands. For a file you hold, you do the work, and it can land anywhere.

Restoring the daily copy into the same project replaces the database with the copy you pick. Supabase says the project is inaccessible while it runs, and that a bigger database takes longer.

Restoring it into a new project is a paid feature Supabase calls Restore to a New Project, still marked beta. It creates a separate project in the same region, with your users and their hashed passwords, and it bills as a second project. One caution from the same page is easy to miss. It copies the entire database, including extensions that act on the outside world such as pg_cron and pg_net, and those jobs start running as soon as the restore completes. If a scheduled job in your app sends email or calls a payment API, the new project starts doing that too, the moment it exists.

Restoring a file you hold means replaying it with psql into whatever you point it at: a new Supabase project, one on a different account, or a Postgres on your own computer. How to restore a Supabase backup goes through the commands, and through what is still broken after it finishes.

How do I get a file copy of my Supabase database?

Take a logical dump yourself. Supabase publishes it in its backup and restore guide as three commands, each writing one file:

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

The connection string comes from the Connect button at the top of your project, with your database password in place of the placeholder. The Supabase CLI needs Docker installed, because it runs pg_dump inside a container rather than using one from your computer.

Keep all three files. The second on its own is the shape of your tables with no rows in it, and your users are only in the third.

You can also run pg_dump directly. Two things to know first. Supabase says a raw pg_dump takes Supabase's own internal schemas along with yours, and that replaying those causes permission errors on the way back in. And Postgres documents that pg_dump will not dump from a server newer than its own major version, so an older copy on your computer refuses to start rather than making a bad file.

Put the files somewhere that is not your Supabase account, and not only your laptop.

Can I restore a Supabase backup on my own machine?

A logical one, yes, into a Postgres of the same major version or newer. The daily physical copy cannot be restored anywhere except Supabase.

The version rule comes from Postgres itself. Its documentation says a dump can be expected to load into newer versions and is not guaranteed to load into an older one, even one the dump came from. Supabase's guide to moving a platform project to self-hosted Supabase shows what that looks like. The platform can run Postgres 17 while the self-hosted image defaults to 15, and the data file then carries a line, SET transaction_timeout = 0, that Postgres 15 does not recognise.

The same three files are also the way off Supabase entirely. That guide is the route to running Supabase on a server of your own, and the version mismatch is the first thing it warns about.

On your own computer, the Supabase CLI runs a local copy of Supabase in Docker when you type supabase start. Replay the three files into it with the psql command from Supabase's backup and restore guide, pointed at postgresql://postgres:postgres@localhost:54322/postgres, and your data is readable on your own computer with no account involved.

There is one place Supabase still offers a backup to download. A free project paused past its restore window swaps the Restore button for a download of the last copy taken before it paused, and what to do with that file is its own article.

What is in neither copy?

Your uploaded files, your Edge Functions, and most of your project's settings.

Supabase says database backups do not include objects stored via the Storage API. The database holds a row describing each file, and the file itself lives somewhere else, so no backup of the database on any plan contains your users' uploads. Backing up Storage is a job of its own.

The list Supabase gives for Restore to a New Project is a good inventory of the rest: Edge Functions, auth settings and API keys, Realtime settings, extension settings and read replicas all have to be set up again by hand.

One gap is specific to the file you hold. If your app keeps secrets in Supabase Vault or uses encrypted columns, Supabase says backup files never contain the root key, only the encrypted data. A new project starts with its own key, so those values come across unreadable until the old key is copied over. And the old key can only be fetched while the old project is still active. Once that project is paused or deleted, the key cannot be retrieved, and neither can anything encrypted with it.

What to do this week

Where Reeve Care fits

Care takes the logical copy for you, keeps it off Supabase, and every copy is a file you can download.

• Download any copy as a zip. Inside are schema.sql, data.sql and roles.sql, a manifest counting the rows in every table, and a note on how to load it into any Postgres. It is a standard dump, so any developer can open it, and so can any other host.
• Stored outside your Supabase account, encrypted, so it is still there on a day the account is not.
• Read back before it counts. The date on your dashboard is the last copy that was opened and verified, never the last one attempted.
• Your users are in it. The auth schema travels with your tables, and the files your users uploaded come too once you connect a Storage credential.

Care keeps a copy of your Supabase database. Leave the daily Supabase backups switched on beside it: they are the fastest way back from a bad migration, and the file is what is left if you lose the account. How a copy is taken, checked and downloaded is drawn step by step on the Supabase backups page, and what each plan includes is on the pricing page.

Before you close this tab, open Database, then Backups, and look beside your newest copy. If there is nothing there to download, the next file you hold is the one you make, and what makes a dump complete is the thing to read before you make it.