Supabase backup tools compared, including ours

You went looking for a Supabase backup tool for one of two reasons. Either you found out your project sits on the free plan and nothing has ever been copied anywhere, or you are on a paid plan, you read how far its window reaches back, and it did not feel like enough for an app with real customers in it.

Here is the part these comparisons get wrong, and the ones written by the tools themselves get wrong hardest: they rank the options by feature. A backup tool is something you pay for to cover a job you have already decided you will not do yourself. If you would genuinely do it, the free route makes the same file.

We sell one of the four below, so read the rest of this with that in hand. For a good number of apps the free route is the right answer, and the section on it is the longest one here.

Which Supabase backup tool should I use?

Choose by which part of the job you want to stop thinking about. All four routes produce a copy of your database. What separates them is how much of what happens next is still yours.

The shaded column is ours, and rows four to six are what it sells. Worth holding against everything below.

What you are actually buying

Four things have to happen for a backup to be worth anything, and every Supabase backup tool here does some of them.

1. Take a copy. Nothing on this page charges you for this. pg_dump ships with Postgres and the Supabase CLI wraps it.
2. Move it somewhere the original cannot take with it. A copy inside the account it is protecting covers you the day you break your own data. It is standing behind the same door the day you lose the login.
3. Read it back. A dump written while a connection dropped looks exactly like a good one until you try to use it.
4. Put it back. On the worst day of your app's life, in whatever state you are in that day, with whatever you happen to know about psql.

Do I need a tool if I am already on a paid Supabase plan?

For the ordinary disaster, no. Supabase takes daily copies on its paid plans and restoring one is a few clicks inside the dashboard, which is the fastest route back from a migration that ran twice.

What it does not cover is the account. Every copy Supabase takes lives inside the project it protects, so a billing failure, a suspended project or a login you cannot recover puts the backups behind the same door as the thing they were there for. Which plan you are on, and how far its window reaches takes about two minutes to check.

So turn those on, and then decide separately whether one copy in one place is where you want to stop.

When a GitHub Action beats paying anyone

When your app already lives in a GitHub repository, you can edit a YAML file without dread, and your database is small. In that case the free route is a real answer. It makes the same dump a paid service makes, on the same schedule, and nobody is billing you.

Supabase documents this one itself. A workflow file in .github/workflows runs the Supabase CLI three times, dumping your roles, your schema and your data as separate files on a cron that fires at midnight, then commits the results back into the repository. Their page carries a single warning and carries it twice: never back up your data to a public repository.

This is also the route that fixes the thing that kills the by-hand version. A pg_dump on your laptop is dated from the last time you thought about it, and the day you need it is never a day you were thinking about it. A scheduled workflow runs whether or not you remembered, and the file lands on a different company's servers from the one holding your database.

Four things it leaves you holding:

• The dumps pile up in a repository, which is a place built for code. A growing binary history is awkward to work with, and if a real secret ever lands in one, taking it back out means rewriting history.
• Your connection string sits in CI. That is a credential with full write access to your database, kept in a system that also runs code from pull requests.
• Nobody reads the copy back. A green workflow run means the job exited without an error, which is a smaller claim than the file restoring.
• Uploaded files need a second job. The dump holds the row pointing at each file. The files live in Storage and come out separately, on every route here.

If you can live with those four, stop reading here and go and set it up, with the connection string GitHub can reach and the schedule your egress allowance can pay for. It costs nothing, and the file it writes is the same file the paid routes write.

What a paid backup service adds

It takes the maintenance off you. A small service connects to your database, runs on a schedule you pick, drops the file into storage you already own, and puts a screen in front of the whole thing that says when a run failed.

Supabackup is the one people search for by name. It takes your database connection string, uploads the dumps into a Google Drive account you connect, and keeps a set number of them before deleting the oldest. Its own pricing page describes a free tier that runs weekly and a paid one that runs daily; read the current price there rather than here, because it is theirs to change.

What that buys over the workflow file is something that does not rot. No YAML, no repository filling with dumps, no CI secret, and a dashboard telling you the last run failed instead of an email you have learned to skip.

What it does not change is the second half of the job. The copy is your database, the file is a dump, and on the day you need it you are the one replaying it. Check whether the service you pick covers Storage as well, because much of this category is the database alone. Restoring a dump has its own steps, and they are worth reading before you need them.

What managed care adds, and what you pay for

It adds the two parts the other three routes leave with you: the check, and the restore.

That is Reeve Care, and backups are one line on it.

• Several copies a day, on a schedule your plan sets and nothing you have to remember to trigger.
• Held outside your Supabase account, encrypted, so a suspended project or a login you cannot recover leaves the copies where they are.
• Read back before it counts. Every copy is opened and counted against what went in, which is why the date on your dashboard is the date of the last verified one rather than the last attempt.
• Your uploaded files alongside your rows, once you connect a Storage credential, and both go back together.
• More than one restore point. How many depends on the plan, and the oldest is pruned as newer ones land.
• Putting it back is one button, and a copy of the current state is taken first, before anything is replaced.

What you pay for is availability. You can start a restore at any hour, from any night your plan still keeps, without waiting until you have a free afternoon. Every copy is encrypted before it leaves your project and held that way. Care Max adds priority support, and somebody to help you apply a fix.

The copy leaving Supabase, the check that follows it and the button that puts it back are drawn out on the Supabase backups page.

How to choose, in about a minute

Four branches, and most people land in the first two.

• Free plan, and editing a YAML file does not frighten you. The GitHub Action. Free, complete, and yours.
• Free plan, and it does. A small backup service, or a copy made from the dashboard by hand until you are ready for something scheduled.
• Paid plan, and you want a copy outside the account. Either of the above, on top of what Supabase already takes.
• Real customers, uploaded files, and nobody who will be running a restore under pressure. Managed.

What to do this week

If a table has ever gone empty on you for a reason nobody could explain, read what a rollback actually restores first, then three ways to back up a Supabase database for what a copy holds and what it leaves behind. And if you would rather see what else is open on your app before you decide where to spend, the free scan reads your live site in about 20 seconds.