Nobody builds a backup strategy on day one. You’re too busy shipping features, watching your AI tool spin up tables and endpoints, and getting the thing in front of users. Then six months in, someone runs the wrong command, a migration goes sideways, or a user clicks delete on the wrong record, and suddenly you’re staring at an empty table wondering if app data loss just ended your business. We’ve had that call more than once. It’s rarely dramatic on the surface. It’s just a founder asking, quietly, “is there any way to get it back?”
Sometimes the answer is yes. Often it isn’t. This guide covers how AI-built apps actually lose data, why “it’s in the cloud” gives you false comfort, and what a proper safety net looks like so you’re not finding out the hard way.
How AI-built apps lose data
AI coding tools are very good at making a database work. They are not, by default, thinking about what happens when something goes wrong. That’s a different skill, and it’s one most prompts never ask for.
The first gap is backups, or rather the absence of them. Supabase, Firebase, and most managed Postgres providers offer backup features, but they’re usually opt-in, tied to a paid plan, or configured with a retention window nobody checked. An AI tool provisioning your database won’t turn on point-in-time recovery unless you specifically ask for it, and most founders don’t know to ask. So the database exists, it’s running fine, and there’s no way to rewind it if something breaks.
The second is destructive migrations. When you ask an AI assistant to “add a column” or “change this field to a different type,” it will often generate a migration that drops and recreates rather than altering in place. That’s fine when the table is empty in development. It’s catastrophic when the same migration runs against production and the drop happens before anyone notices there was no backup. We’ve seen migrations that silently truncate a table as a side effect of a type change, and the founder only finds out when a customer emails asking where their order history went. This is one of the patterns we cover in why your vibe-coded app breaks in production: the code that works in the sandbox and the code that’s safe against real data are not the same code.
The third is hard deletes everywhere. Ask an AI tool to build a “delete account” or “remove item” feature and it will, by default, write a genuine DELETE FROM. No soft-delete flag, no archive table, no thirty-day grace period. That’s a sensible default for a demo. It’s a liability for a real product, because it means every delete button in your app is a one-way door, and one-way doors get walked through by accident constantly, whether it’s a support agent, a confused user, or a bug in a bulk-action script that deletes ten thousand rows instead of ten.
None of this is malicious or even unusual. It’s what happens when a tool optimises for “does the feature work” rather than “what happens when it fails.” If you want a broader sense of where these blind spots come from, why AI coding tools keep making the same mistakes goes into the pattern in more depth.
Why “it’s in the cloud” isn’t a backup
This is the misconception that costs people the most. Your database being hosted by Supabase, AWS, or Firebase means it’s durable against hardware failure. It does not mean it’s protected against you. If your application deletes a row, that deletion replicates everywhere, instantly, because that’s exactly what a database is supposed to do. The cloud provider isn’t going to stop you from shooting yourself in the foot. It’s built to execute your commands reliably, including the bad ones.
A backup is a separate, deliberate copy of your data at a point in time, stored somewhere your live application can’t touch it by accident. “It’s on AWS” tells you nothing about whether that copy exists. We ask this question on almost every assessment we run, and the honest answer is usually “I assumed it was handled.” It generally isn’t, not unless someone configured it on purpose.
The same logic applies to git for your codebase and to your database for your data. Having code in a repository doesn’t back up your rows, and having your database “in the cloud” doesn’t back up anything either unless a retention policy is actually switched on. These are two entirely separate concerns, and AI tools tend to handle neither by default.
The minimum safety net every app needs
You don’t need an elaborate disaster recovery plan for a small SaaS product. You need four things, and most of them take an afternoon.
Automated daily backups with at least seven days of retention, ideally thirty. Most managed database providers offer this as a checkbox, sometimes a paid one. Pay for it. It’s the cheapest insurance you’ll ever buy.
Point-in-time recovery if your provider offers it. Daily backups protect you from “the database vanished.” Point-in-time recovery protects you from “someone deleted the wrong rows at 3pm and we didn’t notice until the next morning.” The difference between those two failure modes is the difference between losing a day of data and losing nothing.
Soft deletes on anything that matters: user accounts, orders, uploaded files, anything a customer would be upset to lose. A deleted_at timestamp column and a filter in your queries costs almost nothing to implement and turns a permanent mistake into a recoverable one.
A tested restore process. This is the one everyone skips, and it’s the one that actually matters. A backup you’ve never restored from is a backup you’re hoping works. We’ve seen backup jobs that had been silently failing for months because nobody checked the logs. If you’ve never actually pulled a backup and restored it to a staging environment, you don’t have a backup strategy, you have a backup wish.
If your app is already handling real customer data and none of this is in place, this is the kind of gap we flag early in our production upgrade guide, because it tends to matter more than almost anything else on the list.
How to check what would happen if something went wrong tomorrow
Here’s a fifteen-minute exercise worth doing this week. Log into your database provider’s dashboard and find the backup settings. Confirm backups are actually enabled, not just available. Check the retention window and note the date of the oldest backup you could restore from.
Then look at your delete functionality. Pick your three most important tables, users, orders, and whatever else your business depends on, and check whether deletes are soft or hard. If they’re hard deletes, that’s your biggest single point of failure, and it’s usually a quick fix.
Then, if you can, actually try a restore. Spin up a staging database from your most recent backup and confirm the data is there and intact. This is the step that turns “we have backups” from a hope into a fact.
If you go through this and can’t answer these questions confidently, that’s worth taking seriously rather than filing away for later. It’s one of the clearer signs your vibe-coded app needs professional help, because unlike a slow page or an ugly form, data loss doesn’t give you a second chance to fix it after the fact.
Not sure your data is safe? Get in touch for a free review and we’ll tell you straight.