Does Supabase back up my database? It depends on your plan.

Someone has told you not to worry about backups, because Supabase does them for you. Whether that is true for your app depends on a billing page you have probably never opened.

Here is the part the reassurance skips: Supabase backs up your database on a paid plan, and not at all on the free one. Not fewer backups, not shorter ones. None. That is not a decision you consciously made either. The free plan is where a project starts.

Does Supabase back up my database?

On a paid plan, yes: one copy a day, taken automatically, kept inside your Supabase project. On the free plan, no. Nothing is copied anywhere on a schedule, and nothing warns you about it.

Those windows are Supabase's own, published in their backup documentation. Read them there rather than here, because they are theirs to change and this page will not notice when they do.

Your builder does not fill the gap either. Lovable, Bolt, v0 and the rest keep a history of your code, which is a different thing from your data and lives in a different place. Version history is not a backup is the long version of why rolling back does not bring a deleted table with it.

How to check which plan you are actually on

Open your Supabase dashboard, choose the project your app talks to, and find Billing under your organization. It takes about two minutes, and it is the only way to know.

Two things make this less obvious than it sounds. Billing sits on the organization, not the project, so two apps under the same login can be on two different plans. And the dashboard moves things around, so if those exact words are not where you expect, look for anything named Billing at the organization level.

While you are in there, open Database and then Backups. A list of dated copies means you have them. An empty panel, or a note that the feature needs a paid plan, is your answer in one screen.

What Supabase's own backups are good at

Quite a lot. They are the first thing to have, not the thing to replace.

They run without you, which is the exact thing that goes wrong with a backup you take by hand: the copy on your laptop is dated from whenever you last thought about it. They are complete, including your Row Level Security policies rather than only the tables those policies protect. And restoring one is a few clicks in a browser rather than a command you have to get right at two in the morning.

They also cover the ordinary way data goes missing, which is that you removed it yourself. A delete that caught more rows than you meant, a migration an AI agent wrote and you approved, a seed script pointed at the wrong project. If that happens on a paid plan, yesterday's copy is sitting right there.

Why a copy inside your account is only half a safety net

Because there are two different ways to lose your data, and a copy kept inside the account only answers one of them.

Supabase parks a spare key inside the house. That is genuinely useful when you lock yourself out of a room. It is no use on the day you lose the house.

The second kind of loss does not involve a mistake in your database at all: a card that expired while you were on holiday, a project suspended, a login you cannot recover, an account somebody else got into. The data and the copies of it are behind the same door, and the door is the thing that closed.

That is not a knock on Supabase. Platform backups are stored with the platform because that is what makes them one click to restore, and the trade is a fair one. It does mean the fix is not to trust them less, but to keep a second copy somewhere that does not share their fate. Three ways to back up a Supabase database compares what each route costs you.

How far back does the window reach?

Seven days on Pro, and the window keeps moving: every new copy pushes the oldest one out the other end.

That is plenty for the mistakes you notice immediately, and a deletion usually announces itself within minutes. The trouble is the quiet kind. A column dropped during a migration nobody read closely. A script that overwrote one field on every row. A form that has been saving the wrong value since Tuesday. Those surface when a customer writes in, and a customer writing in can be a fortnight after the change.

The point is not that seven days is stingy. It is that the length of your window is one number, how long a mistake could sit unnoticed in your app is another, and the two are worth putting side by side before you need them to line up.

Has anyone checked the copy?

If the answer is no, you do not have a backup yet. You have a file, and you find out which one on the day you open it.

A backup that silently stopped working three weeks ago is the worst kind of backup there is, because it feels exactly like protection right up until the moment you open it. A dump that was written while a migration was half applied, or that got truncated when the connection dropped, looks identical to a good one from the outside.

You do not need to buy anything to fix this. Restore one of your own backups into a throwaway Supabase project, open your app against it, and confirm a row you recognise is there. Half an hour, once a quarter, and you find out on a Tuesday afternoon instead of during an outage.

It is also the reason Reeve Care shows you the date of the last copy that passed verification rather than the last one it attempted, and keeps those copies outside your Supabase account. It backs up your database, and the files your users uploaded once you connect your Storage buckets.

What to do this week

Before you close this tab, open your Supabase dashboard and find the plan name. Nothing above is a decision you can make until you know it. The 10-minute security checklist covers backups alongside the rest of what is worth confirming on a newly launched app, and the Supabase safety guide goes through what else is commonly left open.

What Reeve Care adds on top of that

A second copy that does not live in your Supabase account, checked after every run, and a restore you can press without holding your breath.

The point of the comparison below is not that Supabase is doing something wrong. It is that a platform's backup and an independent one answer different questions, and you are allowed to hold both.

One limit and one choice, told straight, because a backup you misunderstood is worse than one you know you do not have. Backups are Supabase only today; if your data lives somewhere else, we say so before you pay rather than after. And the files your users uploaded are copied too, once you connect your Storage buckets. That takes a second key and it is optional, because the key Supabase issues for Storage can write and we would rather ask than assume.

Keep the Supabase backups switched on either way. Two copies in two places is the whole idea, and the cheaper of the two is the one already in your plan.

Backups are not all of it, either: Care watches your app for downtime, re-runs the security scan on a schedule, and sends a monthly report written for someone who does not read logs. What each plan includes, and how often it copies, is in the Care pricing table.

How a copy is taken, checked and put back is drawn out step by step on the Supabase backups page.