[{"data":1,"prerenderedAt":302},["ShallowReactive",2],{"blog-en-version-history-is-not-a-backup":3},{"id":4,"title":5,"body":6,"category":265,"cover":266,"coverAlt":266,"description":267,"draft":268,"extension":269,"faq":270,"image":283,"keywords":284,"meta":290,"navigation":291,"ogTitle":292,"path":293,"published":294,"seo":295,"stem":296,"tldr":297,"updated":294,"__hash__":301},"blog_en\u002Fblog\u002Fversion-history-is-not-a-backup.md","Version history is not a backup. It cannot undo a deleted table.",{"type":7,"value":8,"toc":253},"minimark",[9,13,16,24,29,32,35,38,42,45,48,51,55,58,133,139,142,146,149,152,168,171,175,178,181,184,188,191,196,205,208,216,220,240],[10,11,12],"p",{},"Something broke, so you did the sensible thing. You opened the version history\nin Lovable or Bolt, found this morning's version, and clicked restore. The app\ncame back exactly as it was.",[10,14,15],{},"The data did not.",[10,17,18,19,23],{},"Here is the part that catches people: ",[20,21,22],"strong",{},"your code and your data are two separate\nsystems, and only one of them has an undo button."," Your builder keeps the plans\nfor your app. Your database holds what is inside it. Version history rebuilds\nthe plans perfectly, down to the last detail, and hands you back an identical,\nempty building.",[25,26,28],"h2",{"id":27},"does-my-builders-version-history-back-up-my-database","Does my builder's version history back up my database?",[10,30,31],{},"No. It saves your code, and your data lives somewhere else entirely.",[10,33,34],{},"Lovable, Bolt, v0, Replit, Cursor and the rest all keep a history of your\nproject files: your pages, your components, your logic, your styling. That is\nthe plans. Restoring a version rewrites those files back to how they were on the\nday you picked.",[10,36,37],{},"Your database is a different service, almost always Supabase, sitting on an\naccount of its own. Nothing in your project history reaches into it. The\nrestore has no opinion about your data because it cannot see your data.",[25,39,41],{"id":40},"why-your-code-and-your-data-live-in-two-different-places","Why your code and your data live in two different places",[10,43,44],{},"Because your data has to survive the thing your code does constantly, which is\nchange.",[10,46,47],{},"Your code gets rebuilt every time you ship. If your users' orders lived inside\nit, they would be wiped every time you fixed a button. So the two are kept\napart, deliberately: the code is replaceable and the data is not, and they are\nversioned by different tools for that reason.",[10,49,50],{},"The cost of that separation is the thing this article is about. Every tool that\nversions one of them is blind to the other. Your builder cannot roll back a\ntable, and your database cannot roll back a broken page.",[25,52,54],{"id":53},"what-actually-happens-when-you-roll-back","What actually happens when you roll back",[10,56,57],{},"Your screens go back to how they were. Your data does not move at all.",[59,60,61,74],"table",{},[62,63,64],"thead",{},[65,66,67,71],"tr",{},[68,69,70],"th",{},"What",[68,72,73],{},"Rolling back your code",[75,76,77,86,93,105,115,125],"tbody",{},[65,78,79,83],{},[80,81,82],"td",{},"Pages, components, styling",[80,84,85],{},"Restored",[65,87,88,91],{},[80,89,90],{},"Your app's logic and its bug fixes",[80,92,85],{},[65,94,95,98],{},[80,96,97],{},"A table someone deleted",[80,99,100],{},[101,102,104],"key-verdict",{"type":103},"danger","Still deleted",[65,106,107,110],{},[80,108,109],{},"Rows a bad script overwrote",[80,111,112],{},[101,113,114],{"type":103},"Still overwritten",[65,116,117,120],{},[80,118,119],{},"A column a migration dropped",[80,121,122],{},[101,123,124],{"type":103},"Still dropped",[65,126,127,130],{},[80,128,129],{},"Files your users uploaded",[80,131,132],{},"Not affected either way",[134,135],"diagram",{"alt":136,"caption":137,"src":138},"Three steps in a row. First, code at version five with six rows of data, ticked. Then the same code with all six rows gone, crossed. Then the code wound back to version three and ticked, with the six rows still gone and still crossed.","The rollback lands on the code and nowhere else. Winding the plans back to version three does not put the rows back.","\u002Fblog\u002Fversion-history-is-not-a-backup\u002Frollback-timeline-1600x680.png",[10,140,141],{},"The migration row is the one that surprises people most. A migration you ran\nagainst your database has already happened; it lives in the database, not in\nyour repository, and reverting the file that described it changes nothing.",[25,143,145],{"id":144},"where-this-actually-bites","Where this actually bites",[10,147,148],{},"In the ten minutes after a mistake, when you go looking for the undo and find\nout there is not one.",[10,150,151],{},"The shapes it takes are ordinary:",[153,154,155,159,162,165],"ul",{},[156,157,158],"li",{},"A delete in the Supabase table editor that matched more rows than you meant.",[156,160,161],{},"An AI-assisted migration that dropped a column to make a type error go away.",[156,163,164],{},"A seed or reset script pointed at the live project instead of a test one.",[156,166,167],{},"A tidy-up of what looked like test data and turned out to be somebody's real\naccount.",[10,169,170],{},"None of these touch a single line of your code. Every one of them survives a\nrollback completely intact, which is why the rollback feels like it did nothing.\nIt did exactly what it does.",[25,172,174],{"id":173},"what-version-history-is-genuinely-good-for","What version history is genuinely good for",[10,176,177],{},"Quite a lot, and it is worth being clear about, because the answer is not\n\"nothing\".",[10,179,180],{},"It is a real undo for real problems: a design change you regret, a deploy that\nbroke a page, an AI edit that rewrote a working screen into something worse, a\nfeature that turned out to make the app harder to use. All of those live in your\ncode, and for those it works exactly as advertised.",[10,182,183],{},"The trouble is the quiet assumption that its job covers everything. That is not\nan assumption anyone makes on purpose; it is the one you are left with when\nnobody tells you there are two systems.",[25,185,187],{"id":186},"how-to-get-an-actual-undo-for-your-data","How to get an actual undo for your data",[10,189,190],{},"You have to put one there. That means a copy of the database, taken on a\nschedule, kept somewhere that losing the account would not also take.",[134,192],{"alt":193,"caption":194,"src":195},"Two timelines. On the code timeline an arrow curves back from the latest point to an earlier one on its own. On the database timeline the same arrow only completes by passing through a saved file.","Both can go backwards. The difference is that your code's undo came with the builder, and your data's only exists if you put the copy there yourself.","\u002Fblog\u002Fversion-history-is-not-a-backup\u002Ftwo-undo-paths-1600x600.png",[10,197,198,199,204],{},"There are three ways to do it, they cost different amounts of money and\nattention, and each misses something the others cover.\n",[200,201,203],"a",{"href":202},"\u002Fblog\u002Fthree-ways-to-back-up-a-supabase-database","Three ways to back up a Supabase database","\nwalks through all three, including the one most people should turn on first and\nthe reason it is not enough on its own.",[10,206,207],{},"That is also what Reeve Care is for: scheduled copies of your Supabase database,\nheld outside your Supabase account and checked before they count as taken.\nConnect your Storage buckets and the files your users uploaded ride along, so a\nrestore puts back the rows and the images those rows point at.",[10,209,210,211,215],{},"What one of those copies holds, and what pressing restore actually does, is on\nthe ",[200,212,214],{"href":213},"\u002Fsupabase-backups","Supabase backups page",".",[25,217,219],{"id":218},"what-to-do-this-week","What to do this week",[221,222,223],"key-takeaways",{},[153,224,225,228,231,234,237],{},[156,226,227],{},"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.",[156,229,230],{},"Turn on whatever backup your Supabase plan includes. It protects you against your own mistakes, which is the failure this article is about.",[156,232,233],{},"Keep one copy somewhere else as well, because a backup living inside the account cannot help you if you lose the account.",[156,235,236],{},"Back up your uploaded files separately. They are in neither your code nor your database.",[156,238,239],{},"Restore one copy into a throwaway project, so the first time you read that file is not the day you need it.",[10,241,242,243,247,248,252],{},"Before you close this tab, open your Supabase project and look at whether\nbackups are on. That single check is the whole of today's work. The\n",[200,244,246],{"href":245},"\u002Fchecklist","10-minute security checklist"," covers it alongside the other things\nworth confirming on a newly launched app, and the\n",[200,249,251],{"href":250},"\u002Fis-your-supabase-app-safe","Supabase safety guide"," goes through what tends to\nbe left open.",{"title":254,"searchDepth":255,"depth":255,"links":256},"",3,[257,259,260,261,262,263,264],{"id":27,"depth":258,"text":28},2,{"id":40,"depth":258,"text":41},{"id":53,"depth":258,"text":54},{"id":144,"depth":258,"text":145},{"id":173,"depth":258,"text":174},{"id":186,"depth":258,"text":187},{"id":218,"depth":258,"text":219},"Backups",null,"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.",false,"md",[271,274,277,280],{"q":272,"a":273},"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.",{"q":275,"a":276},"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.",{"q":278,"a":279},"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\".",{"q":281,"a":282},"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.","\u002Fblog\u002Fversion-history-is-not-a-backup\u002Fcard-800x500.png",[285,286,287,288,289],"lovable version history","version history database backup","undo deleted supabase table","rollback code restore data","recover deleted data vibe coded app",{},true,"Version history is not a database backup","\u002Fblog\u002Fversion-history-is-not-a-backup","2026-08-10",{"title":5,"description":267},"blog\u002Fversion-history-is-not-a-backup",[298,299,300],"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.","S8jUY943zu5PFNIypSviZUizNCZ3qeFVETysdibiOhg",1787826048204]