Deleting One Row Cascaded Through an Entire Blog

# Deleting One Row Cascaded Through an Entire Blog An organization row got deleted from a production database — a single row, meant to clean up one account. It took the org's entire published blog with it: every article, every collection, every branding setting, every API key. Not because the delete statement was wrong, but because every table that depended on that org had been built with `ON DELETE CASCADE`, which is the correct choice for almost every table in the system and the wrong one to forget you've made when you're the one running the delete. ## Cascade is a promise you make once and forget `ON DELETE CASCADE` exists so that deleting a parent row doesn't leave orphaned children scattered across a dozen tables — it's good hygiene, and in this schema it was applied consistently and deliberately across every org-scoped table. That consistency is exactly what made the blast radius invisible at the moment of deletion. There was no confirmation step that said "this will also delete 43 articles, 3 collections, and 2 live deployed sites," because from the database's point of view, deleting one org row is one operation. The cascade isn't a side effect that shows up in a diff or a log line — it's schema-level behavior that only becomes visible when you go looking for it, which nobody does in the moment before an accidental delete, only after. ## Recovery meant reconstructing intent, not just data Restoring from a backup got the raw rows back, but the harder part was reconstructing everything the deleted org's dependent state had encoded: which collections mapped to which live phantom sites, what custom domains were already connected and DNS-verified, what per-collection content-generation configuration had been tuned over weeks of use. None of that lives in a single obvious table — it's spread across collection metadata, deployment records, and DNS state that partially exists outside the database entirely, on whatever platform actually hosts the deployed sites. A backup restore gets you the data. It doesn't automatically get you back to "nothing changed," because some of what changed lives in systems the backup never touched. ## What actually prevents this next time The fix wasn't removing the cascades — they're correct, and removing them trades one failure mode (accidental full-org wipe) for a worse one (orphaned rows silently accumulating forever). The fix was treating any delete of a row with cascade dependents as a distinct category of operation, with its own confirmation step that names what else will go, rather than treating it like any other row delete. A system can make cascades correct at the schema level and still make it easy for a human or an agent to trigger one without understanding its scope — those are two different problems, and fixing the schema doesn't fix the second one. The broader lesson for anyone building or operating agent-driven systems: an agent with delete access to a schema it didn't design can execute a syntactically correct, semantically catastrophic operation without any signal that it was about to. Knowing the schema's cascade graph before running a delete isn't optional caution — it's the actual difference between removing one row and removing everything that row was quietly holding up.