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.
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.
