Delete one note. Lose every note.
In this controlled demo, the delete button sends the note's ID, but the database query never uses it. Deleting one note removes every row in the table.
Demo built and tested 1 Oct 2026 · Published 1 Oct 2026 · Last reviewed 1 Oct 2026 · By Ctrl+Z Therapy (how we test)
Why did deleting one item delete everything?
Because the delete query has no filter. The button sends the item's ID, but if the query never uses it (no WHERE clause), the database deletes every row in the table. In our controlled demo, deleting one note removed both notes. The fix: delete only where the ID matches and the item belongs to the signed-in user, and check that exactly one row changed.
How to tell if your app has this
No code needed.
- In a test copy of your app, create two items and delete one. If both disappear, you have this bug.
- Ask your AI tool: "Show me every delete and update query. Does each one filter by the item's ID and the signed-in user?"
- Find out whether you could get deleted data back at all: backups, version history, or a "deleted" flag instead of removing the row.
Before and after
Deleted note 1. Both notes were gone.
Deleted note 1. Note 2 is still there.
Why AI-built apps end up with this
When an AI tool rewrites a query, a filter can get lost, and a delete without a filter is still valid SQL, so nothing shows an error. It is easy to miss in testing, because a test database often has one row, and deleting it looks correct.
How do I fix it? Paste this into your AI tool
In my app, deleting one item deleted every row, because the delete query doesn't filter by the item's ID. Find every delete and every update in the code. Make each one filter by the item's ID and by the signed-in user, for example DELETE FROM notes WHERE id = ? AND owner_id = ?, and check how many rows it changed: exactly one is expected, anything else is an error. If we use Supabase, make sure row level security also limits deletes to the user's own rows. Then test it on a copy of the data, never the real database: delete one item and check that the others are still there, and that another user can't delete it.Works with Lovable, Bolt, Cursor, Replit and similar tools. Then run the check-up below on your own app.
How we checked the fix
| Same request | Before | After |
|---|---|---|
| Sam deletes note 1 (Sam has 2 notes) | 2 rows deleted, 0 left | 1 row deleted, note 2 left |
| Bob tries to delete Sam's note 1 | Not tested | 0 rows deleted |
Results from our demo test, run against the same demo before and after the fix.
Common mistakes when fixing this
- Test deletes on a copy of your data, never on the real thing.
- Updates have the same trap: an UPDATE without a filter changes every row.
Questions people ask
Can I get the deleted rows back?
Only from a backup or version history taken before the delete. Restoring your code doesn't bring data back. Not sure your backups restore? See Case 021.
Does row level security stop this?
It limits a delete to the rows the user is allowed to delete, so one user can't wipe everyone's data. A user can still lose all of their own rows if the query has no ID filter.
What is a soft delete?
Instead of removing a row, you mark it as deleted and hide it, so a mistake can be undone. You still need the ID filter.
For developers: the cause and the fix in code
− DELETE FROM notes + DELETE FROM notes + WHERE id = ? AND owner = ? -- expect exactly 1 row
Simplified. Your stack will look different; the principle is the same.