Unexpected hard deletes happening on table (even after direct SQL inserts)
Hi, I’m running into a critical issue with my Supabase Postgres database.
We continuously insert rows into a table, and the id column is an auto-incrementing primary key. What I noticed is that rows are suddenly deleted from the table, even though:
• Our application logic never calls DELETE.
• We only implement soft deletes (UPDATE is_deleted = true) in both server and client code.
• The id sequence keeps increasing, which suggests this is not a rollback or reset, but actual DELETE operations.
• This also happens when I insert rows directly from the SQL editor in Supabase — the rows disappear later on.
Environment details:
• Supabase hosted Postgres
• Client uses anon key only, server uses service_role (kept secret)
• RLS enabled, with policies intended to block hard deletes
• No known triggers or cron jobs that should perform deletions
Questions:
1. What are possible causes for unexpected hard deletes in Supabase (e.g., FK cascades, hidden triggers, RLS misconfiguration)?
2. How can I reliably trace which session or user executed the DELETE? (via Supabase logs, Postgres audit, or other means)
3. Are there any known cases where ORM/SDK behavior could silently issue a DELETE (e.g., upsert or conflict resolution edge cases)?
4. Since the issue occurs even with direct SQL inserts, could there be any background process, policy, or Supabase-internal mechanism that might remove rows?
Any guidance on where to look next or how to debug this would be greatly appreciated.
5 Replies
1. I think you listed most of the possibilities, another could be someone deleting them
2. Logs are your friend except when they don't show stuff like delete from the table view, there is also an audit log but I'm not sure what it shows https://supabase.com/dashboard/account/audit
3. Nope, this would have to be something you do yourself
4. Supabase doesn't have any such policy or process. You would have to be the one who set this up yourself.
There is likely no one deleting them.
Postgres can use up ids when doing updates, or inserts that fail. Also upserts can use them up. It also caches ahead in the sequence and can lose from there.
CYBERTEC PostgreSQL | Services & Support
Gaps in sequences in PostgreSQL
How you can end up with gaps in sequences & how they can even skip backwards. How to build a gapless sequence in PostgreSQL.
The user seems to be saying they noticed rows were deleted in the table, so I'd assume data was deleted.
Yeah, reading closer it is not just the missing ids they mention.