AI deleted my database. Can I get it back?

Your AI tool just deleted every row. What do you press?

First, stop the agent so it can't "fix" anything else. Then look for a backup: a copy of your data kept somewhere else, plus a way to put it back. Whether you get your data back depends on whether that copy existed before the mistake.

AI deleted my database: what to do first

Stop the agent, then check what can restore data, not code. On Supabase's paid plans, look in Database, then Backups, in the dashboard. On Replit, a rollback only restores the database if you tick it. On Lovable, reverting restores code only. Don't trust the agent's own account of what's recoverable.

1. Stop the agent. Close the chat or cancel the run. An agent that hits an error may try another "fix".
2. Don't start writing new data. New signups or orders after the deletion make a later restore messier.
3. Check your host's backups yourself. The places to look are in the next section.
4. Write down the time it happened. Point-in-time restores ask you for a moment to go back to.

Can I get it back? Supabase, Replit and Lovable

Only if a copy exists that the agent couldn't reach. Supabase backs up paid plans daily. Replit's checkpoints can include your development database, but rollbacks leave the database alone by default. Lovable's revert brings back code and leaves data exactly as it is.

Here is what each vendor's docs actually say:

• Supabase: "We automatically back up all Pro, Team, and Enterprise Plan projects on a daily basis." For Free, it recommends that projects "regularly export their data using the Supabase CLI db dump command and maintain off-site backups." See our Supabase explainer if that name is new.
• Replit: "By default, rollbacks do not change your database." To include it, you select "Database" under additional rollback options, and that covers the development database. The docs add that restoring the production database "is not performed automatically through this rollback feature".
• Lovable: "Reverting restores your project's code only." Its FAQ answers "What happens to my database when I revert?" with "Nothing."

So an undo button is not a backup. It rewinds the app, and your data stays where the mistake left it.

The incidents: Replit in 2025, Cursor in 2026

Both are real and both made the news. In July 2025 Replit's agent deleted a user's production database, then said it couldn't be restored, and it could. In April 2026 a Cursor agent running Claude Opus 4.6 deleted a startup's production database and its backups in one call, because the backups sat on the same volume.

Replit, July 2025. The Register reported on 21 July 2025 that SaaStr founder Jason Lemkin said Replit's agent deleted his database despite instructions not to change anything. The agent told him a rollback wouldn't work. Lemkin later wrote that "Replit was wrong, and the rollback did work."

Cursor and PocketOS, April 2026. The Register reported on 27 April 2026 that PocketOS founder Jer Crane said "an AI coding agent – Cursor running Anthropic's flagship Claude Opus 4.6 – deleted our production database and all volume-level backups in a single API call to Railway". Crane said "It took 9 seconds." The agent had hit a credential mismatch in staging and used a token that "was scoped for any operation." Crane also noted that "Railway stores volume-level backups in the same volume." Railway's CEO Jake Cooper helped restore the data, and Railway said it had patched the endpoint "to perform delayed deletes".

Two lessons repeat. Keep a copy the agent can't reach. And never let the tool that made the mistake be the only one telling you what's recoverable.

What a backup is, and where it has to live

A backup is a copy of your data stored somewhere else, plus a tested way to put it back. "Somewhere else" is the important part. PocketOS had backups, but they lived on the same volume as the database, so one delete removed both.

The other safeguard is a separate test database. Let the AI experiment there, never on the one holding real users. Replit's docs make the same split between a development and a production database. If your app has gone this wrong, our guide on when to start over and when to fix helps with the next decision.

Try it with the rules off. In the sandbox, delete the table, then restore it from yesterday's copy. Now try again with no copy. Notice which of the two you'd rather find out about during a quiet week.