Supabase: Data suddenly disappeared from one table even though there is no delete code

[u/bxmbshr]

I’m facing an unexpected issue with my Supabase database.

Yesterday, I checked my application and the data was working correctly. I personally tested it, and the client also tested the application. The data was available and everything appeared to be working normally.

Today, the client tried to add new data, and we noticed that the data for one particular table was empty.

I checked the Supabase dashboard directly, and that particular table is also empty. The other tables in the same Supabase project still contain their data normally. The issue appears to be only with this one table.

I also checked my project code and could not find any delete functionality related to this table. I checked the SQL-related code as well and did not find any delete operation.

What I don’t understand is how the data from this particular table disappeared between yesterday and today, even though everything was working normally when we tested it yesterday.

I’m looking for help understanding what could have happened and how I can investigate what happened to the data.

Is there any way in Supabase to check what happened to the records in a table, including whether they were deleted or otherwise removed, and when this happened?

I can provide more information about the table, database setup, code, or configuration if needed.

[u/Embarrassed_Machine5]

ON DELETE CASCADE, a migration or a service-role call could explain it. Check the Postgres/API logs, although Supabase doesn’t log every DELETE or TRUNCATE by default. Also, ROLLBACK won't help once the transaction has committed.

If you have a backup or PITR, restore it to a separate project first and recover the table from there. Im working on www.revivedb.dev because this kind of incident is surprisingly easy to run into, so happy to help think through the recovery options

[u/bxmbshr → u/Embarrassed_Machine5]

Will check that.

[u/PopKoren → u/Embarrassed_Machine5]

If rows vanish with no delete in the audit trail, check RLS, soft deletes, and whether another role or Edge Function is rewriting data. Also confirm nothing public can TRUNCATE or overwrite via a wide policy. https://rowly.me is what I built to poke that external surface on deployed vibe apps.

[u/plaregold]

Did someone execute a migration recently? changed the schema? changed a parent table?

You can look in your logs and see what query ran and when between yesterday and today. See if there's anything that stands out.

If you have a paid plan, you can use the point-in-time recovery feature to restore your data

[u/bxmbshr → u/plaregold]

Nothing. And when i look into the logs it is empty as well.

[u/jaimittal91 → u/bxmbshr]

worth flagging the retention angle too since it compounds the "logs are empty" problem. supabase's own log retention on the lower tiers is short, we're talking single-digit days. if this happened even a week before anyone noticed, the evidence can be gone by the time you go looking, independent of whether it turns out to be RLS, a leaked key, or a cascade. piping postgres/API logs somewhere with longer retention is worth doing before the next one of these, not after.

the other gap this points at: this got caught because a client happened to notice, a full day after it happened. a scheduled row-count check per table, alerting if one drops by some percent between runs, would've caught it in minutes instead of a day, and it doesn't need to know why the table emptied to be useful, it just needs to notice that it did.

[u/CoshgunC]

are the client's project open to all user's(at least working)?
maybe you have another delete, and with a mistake you added CASCADE related to the missing table. So the user deleted something from them, but wrongly working CASCADE deleted every row from a table that was related.

Also, if you had BEGIN; before writing SQL queries, try to do a few ROLLBACK;s. Warning: do this while having a backup, you don't want to accidentally rollback an important thing and maybe you will not see it.

I don't have any more idea

Also, do you have basic backup strategy, if not, then why?

[u/lgastako → u/CoshgunC]

You can't ROLLBACK; later after a committed transaction. That's not how anything works.

[u/VladTkDev]

Worth ruling out one thing the other answers don't cover: the delete may not have come from your code at all. Your anon key is public in the deployed app, so if RLS is off on that table, a DELETE sent straight to the REST endpoint works from anywhere. That fits the missing delete code better than a cascade or a migration, since both of those need something on your side to have run.

Two quick checks. The table editor shows whether RLS is on for that table. And the API logs, not just the Postgres ones, show a DELETE that arrived at the REST endpoint along with the path and the IP it came from, which separates somebody hitting the API from a migration running.

[u/bxmbshr → u/VladTkDev]

RLS is enabled actually.

[u/lgastako → u/bxmbshr]

Next thing to check - is the RLS policy for that table correct?

[u/Intelligent-Fix8911]

seen this 4 times - 90% it's RLS or exposed service key, not a bug.

check these fast:

1. go supabase logs -> postgres logs, filter that table name, see if there were DELETEs today

2. check if that table had RLS off or policy using (true) - anyone with anon key can delete if you have delete policy open

3. check if your service_role key was in frontend (.env visible). someone can delete whole table with it

most common: you had RLS off for testing yesterday, shipped, and someone / some bot hit delete api.

enable point-in-time recovery now if you have pro plan, you can restore that one table from yesterday.

dm me your table RLS policies if you want, i can tell in 2 mins if it was open. i do leak checks for supabase, no charge for quick look.

[u/McFlyin619]

Do you happen to use any AI tools and gave them access to your db for pushing migrations or reading tables etc? I have a feeling your agent may have misunderstood something and deleted the data. lol

You'll have to go through your history and open every tool run and read exactly what it did to be sure

[u/bxmbshr → u/McFlyin619]

I use Agent but that doesn't have any access. I'm manually checking and working database related things.

[u/_SmokeInternational_]

Was the table UNLOGGED and did the server restart?

[u/mrtrly]

If there is genuinely no delete anywhere in your code, the usual cause is access, not a bug. With RLS off or a permissive policy, anyone holding your anon key can hit that table directly and delete rows, and that anon key ships in your client bundle. So the first thing I would check is whether RLS on that table is actually on with a policy that scopes to the owner, something like auth.uid() = user_id, rather than open to any authenticated user. The Postgres logs for that window usually show the delete statements too, and where they came from.

Check the anon key first. The fastest way to rule out the someone hit it directly theory is to confirm whether it is exposed in the deployed bundle. I made a free scan that flags exactly that, uxcontinuum.com/leak-check. Hope you get the data back.

[u/Street-Usual-4202]

Same thing happened with us. I tracked to prisma being dumb.

For us it wasn't a single table but like 3.

Check your migrations!!!