Reeve Backups
Version history is not a backup. It cannot undo a deleted table.
Lovable and Bolt keep version history for your code. Your database is a separate service, so rolling back to this morning does not bring your data back.
In short
- Version history restores your code. It never touches your database, which is where your users, their content and their orders actually live.
- That means a deleted table, an overwritten row or a bad migration survives a rollback completely intact.
- Your code has an undo built in. Your data only has one if you put it there.
Something broke, so you did the sensible thing. You opened the version history in Lovable or Bolt, found this morning's version, and clicked restore. The app came back exactly as it was.
The data did not.
Here is the part that catches people: your code and your data are two separate systems, and only one of them has an undo button. Your builder keeps the plans for your app. Your database holds what is inside it. Version history rebuilds the plans perfectly, down to the last detail, and hands you back an identical, empty building.
Does my builder's version history back up my database?
No. It saves your code, and your data lives somewhere else entirely.
Lovable, Bolt, v0, Replit, Cursor and the rest all keep a history of your project files: your pages, your components, your logic, your styling. That is the plans. Restoring a version rewrites those files back to how they were on the day you picked.
Your database is a different service, almost always Supabase, sitting on an account of its own. Nothing in your project history reaches into it. The restore has no opinion about your data because it cannot see your data.
Why your code and your data live in two different places
Because your data has to survive the thing your code does constantly, which is change.
Your code gets rebuilt every time you ship. If your users' orders lived inside it, they would be wiped every time you fixed a button. So the two are kept apart, deliberately: the code is replaceable and the data is not, and they are versioned by different tools for that reason.
The cost of that separation is the thing this article is about. Every tool that versions one of them is blind to the other. Your builder cannot roll back a table, and your database cannot roll back a broken page.
What actually happens when you roll back
Your screens go back to how they were. Your data does not move at all.
| What | Rolling back your code |
|---|---|
| Pages, components, styling | Restored |
| Your app's logic and its bug fixes | Restored |
| A table someone deleted | Still deleted |
| Rows a bad script overwrote | Still overwritten |
| A column a migration dropped | Still dropped |
| Files your users uploaded | Not affected either way |
The migration row is the one that surprises people most. A migration you ran against your database has already happened; it lives in the database, not in your repository, and reverting the file that described it changes nothing.
Where this actually bites
In the ten minutes after a mistake, when you go looking for the undo and find out there is not one.
The shapes it takes are ordinary:
- A delete in the Supabase table editor that matched more rows than you meant.
- An AI-assisted migration that dropped a column to make a type error go away.
- A seed or reset script pointed at the live project instead of a test one.
- A tidy-up of what looked like test data and turned out to be somebody's real account.
None of these touch a single line of your code. Every one of them survives a rollback completely intact, which is why the rollback feels like it did nothing. It did exactly what it does.
What version history is genuinely good for
Quite a lot, and it is worth being clear about, because the answer is not "nothing".
It is a real undo for real problems: a design change you regret, a deploy that broke a page, an AI edit that rewrote a working screen into something worse, a feature that turned out to make the app harder to use. All of those live in your code, and for those it works exactly as advertised.
The trouble is the quiet assumption that its job covers everything. That is not an assumption anyone makes on purpose; it is the one you are left with when nobody tells you there are two systems.
How to get an actual undo for your data
You have to put one there. That means a copy of the database, taken on a schedule, kept somewhere that losing the account would not also take.
There are three ways to do it, they cost different amounts of money and attention, and each misses something the others cover. Three ways to back up a Supabase database walks through all three, including the one most people should turn on first and the reason it is not enough on its own.
That is also what Reeve Care is for: scheduled copies of your Supabase database, held outside your Supabase account and checked before they count as taken. Connect your Storage buckets and the files your users uploaded ride along, so a restore puts back the rows and the images those rows point at.
What one of those copies holds, and what pressing restore actually does, is on the Supabase backups page.
What to do this week
What to do
- Find out whether anything is currently backing up your database. Not your code. Your database. If the answer takes more than a minute to establish, the answer is no.
- Turn on whatever backup your Supabase plan includes. It protects you against your own mistakes, which is the failure this article is about.
- Keep one copy somewhere else as well, because a backup living inside the account cannot help you if you lose the account.
- Back up your uploaded files separately. They are in neither your code nor your database.
- Restore one copy into a throwaway project, so the first time you read that file is not the day you need it.
Before you close this tab, open your Supabase project and look at whether backups are on. That single check is the whole of today's work. The 10-minute security checklist covers it alongside the other things worth confirming on a newly launched app, and the Supabase safety guide goes through what tends to be left open.
FAQ
I deleted a table by mistake. Can I get it back?
Only from a backup taken before the delete, so the first thing to find out is whether one exists. Rolling your code back will not do it, and neither will anything in your builder. If you are on a paid Supabase plan there are daily backups, and point-in-time recovery if you added it. On the free plan there is nothing automatic. Check what you have before you change anything else, because some recovery routes get harder once you start writing new data over the gap.
Does Lovable back up my Supabase database?
Your builder versions your project files. Your database is a separate service on your own Supabase account, and nothing in the project history reaches into it. Builders do add features, so check your own builder's documentation rather than assuming either way. But assume the answer is no until you have read that it is yes.
Is my Git history a backup?
No, for exactly the same reason version history is not. Git tracks the files your app is built from. It has never seen a single row of your data, and it cannot put one back. A repository and a database are different kinds of thing that happen to both be called "your project".
My data is all still there. Do I need to do anything today?
This is the cheapest day you will ever have to set this up, because the data is small and what actually matters is that the habit exists before you need it. The losses that hurt are rarely dramatic. They are a mistyped command during a late-night fix, on a project with just enough real users that starting over is not an option.