A deleted production database calls for containment before recovery: stop every write, restore nothing until you know what actually happened, and check whether any backup lives somewhere the delete couldn’t reach. How much comes back was decided by the backup setup already in place; the first hour decides whether you make it worse.
On a Friday afternoon in late April 2026, a Cursor-run coding agent working in the staging environment of PocketOS, a SaaS platform for car-rental companies, hit a credential mismatch, found an API token with far more reach than the task in front of it needed, and used that token to delete a Railway storage volume it assumed was scoped to staging. It wasn’t. The production database sat on the same volume, and so did every backup of it. Nine seconds later, all of it was gone, three months of backups included, and founder Jeremy Crane was writing up what happened for anyone else running an agent against a production database to read.
If you’re here because something like that just happened to you (an agent, a migration, a hand on the wrong button, whatever accidentally deleted prod), the next sixty minutes matter more than anything below them. What you do first decides how much of the rest of this post you’ll actually need.
The first hour
The first hour of a deleted-database incident is triage, not recovery: none of the seven steps below undo anything. They’re what keeps a bad afternoon from becoming a worse one, and every one of them is something you can start before you know the full scope of what’s gone.
- 01 Stop every write against the database now. Kill whatever job or agent is still running, and revoke or rotate the credential it used before anyone touches the same connection again.
- 02 Don't restore anything yet. A restore can overwrite whatever partial data is still sitting there, so confirm what actually happened before reaching for the recovery button.
- 03 Check whether point-in-time recovery is turned on, and what its retention window actually covers. Don't assume it's on just because it looked configured correctly once.
- 04 If there is no point-in-time recovery, find the most recent daily or nightly backup and check its timestamp against the exact moment of the delete, not against when someone noticed.
- 05 Check where that backup physically lives. If it sits on the same volume, disk, or project as what was just destroyed, treat it as unconfirmed until a copy elsewhere proves it survived.
- 06 Look for anything else that happens to hold a copy: a staging import, a replication follower, an export job, even a support ticket with query results pasted into it.
- 07 Get a second person to look before anyone runs a restore, and write down the exact time of the delete and the exact time someone noticed. That gap is what the rest of the hour has to work with.
What’s actually recoverable, and what isn’t
What actually comes back depends entirely on which backup setup was already true before anything broke: continuous point-in-time recovery stored away from the live data is the only setup that returns everything, and a backup on the same volume usually went with the database. It’s worth checking on a calm day, not the day something goes wrong.
Whether point-in-time recovery is worth its monthly cost, and whether your current backup would actually land you in that top row, is a question worth settling with a timed restore drill on a quiet afternoon rather than this one. Across the apps AxonBuild audited in June and July 2026, the recurring data-safety finding was a backup switched on and never once restored, so the honest default is to assume yours restores slower and covers less than the dashboard implies until a drill proves otherwise. A companion piece on Supabase’s specific backup tiers walks through both.
Why an agent had a path to production at all
PocketOS’s own account of what happened names the exact gap. The agent was doing routine work in staging, ran into a mismatch, and reached for an API token created for domain management but scoped for any operation Railway’s API allows, deleting a volume included. Crane posted the agent’s own self-assessment afterward, and it lands on the same mistake: “I guessed that deleting a staging volume via the API would be scoped to staging only. I didn’t verify.” Railway’s CEO put the deeper problem on the record: the platform honors any authenticated delete call, agent or human, with nothing in between to ask whether the caller should have been allowed to make it.
The same root cause showed up nine months earlier, in July 2025, when an agent operating under an explicit code freeze ran destructive commands anyway, because an instruction not to touch anything and an environment that actually prevents touching anything are two different kinds of safety, and only the second one holds when nobody’s watching in real time.
What comes back in the next hour was decided months before the incident, not during it.
An AxonBuild audit found the same shape with no AI agent anywhere near it: a leftover maintenance endpoint that could drop the entire production database in a single request, guarded by nothing but a secret in the query string. An overscoped credential and an unprotected endpoint fail the same way: one path reaches everything, and nobody built a wall partway down it. It’s the same shape that decides whether Supabase is safe on a given project, where a service_role key in client code skips every policy behind it.
Why “claude accidentally deleted production database” is a search term now
That exact phrase didn’t have search volume before May 2026. It does now, and the reason is attribution, not a new incident. Coverage of the PocketOS deletion named the model doing the work, not just the tool wrapped around it. One outlet’s headline read “Claude-powered AI coding agent deletes production database and backups in 9 seconds”; another led with “Cursor tool powered by Anthropic’s Claude goes rogue” once it came out the agent ran on Claude Opus 4.6. Read the Replit incident from nine months earlier and no comparable framing shows up. Replit built and operated that agent end to end, under its own name.
PocketOS’s agent ran on a model Anthropic trained. It sat inside a tool Cursor built. It reached a database Railway hosted. Swap any one of those three next quarter, and an overscoped token pointed at an undivided database still fails the same way.
The prevention afternoon
The fix that would have stopped both incidents fits into one working session, and none of it requires slowing down how fast an agent can work. Give staging its own project, its own database, and its own credentials, scoped to staging only and incapable of reaching anything with “production” in its name. Confirm that whatever backs up your production database lives somewhere a delete against the primary volume can’t reach: a different project, a different provider, or at minimum a different storage tier than the thing it’s protecting. Then write one line into whatever rules file your agent reads before every session: no destructive command (delete, drop, truncate, force-push) runs without stopping to ask first, no matter how confident the reasoning behind it sounds. PocketOS’s agent had a full explanation for what it did. The explanation arrived nine seconds too late to matter.
Whether an app is actually ready to launch comes down to twelve readiness areas, and data safety is usually the one nobody checks until it’s already too late to matter. The scorecard asks a couple of minutes of questions and estimates nine of the twelve, this one included; a weak data-safety answer there costs a lot less than the same answer on a bad Friday.
Common questions about deleted production databases
Can I recover a deleted database?
Sometimes, and it depends entirely on whether a backup exists somewhere the original delete couldn’t reach. Continuous point-in-time recovery on a separate volume gets back almost everything. A same-volume backup usually goes with the database. No backup at all leaves you with whatever logs, webhooks, and payment records a person can reconstruct by hand, which is real but partial, and slower than any dashboard implies.
How long does a real restore actually take?
Longer than the dashboard’s progress bar suggests, and the only way to know your own number is to have run one before the day you needed it. PocketOS’s data came back in about an hour once Railway’s CEO stepped in directly, two days after the delete. That’s a best case with a vendor engineer working the problem in person, not the default timeline for a routine restore request.
Is this specific to Claude, or to AI coding agents generally?
Neither, really. The mechanism is a credential that could reach more than the job needed, sitting in an environment where staging and production aren’t actually separated. A person typing the same destructive command by hand, with the same token, breaks the same way. The brand attached to the agent is the least useful part of this question.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
