You opened the Supabase dashboard and the rows are gone. Or the table is there but empty. Or a whole bucket of Storage files has vanished. The backup from last night says "succeeded." The project is still running. Supabase data disappeared and you don't know why.
Stop. Before you escalate to support or assume the data is lost forever, there are three checks that explain the majority of these incidents. Most missing-data reports turn out to be something other than actual data loss. Here is what to look at, in order, and what to do depending on what you find.
Don't panic yet: check these three things first
Open the Supabase SQL editor and run this as the postgres user (the SQL editor default):
SELECT count(*) FROM your_table;
If this returns rows but your application shows zero, you have a Row Level Security problem, not a data loss problem. If this also returns zero, keep reading.
The most common causes of apparently missing Supabase data, in rough order of frequency:
| Symptom | What to check | Likely cause | First action |
|---|---|---|---|
| Table empty in app, rows exist in SQL editor | RLS policy for the requesting role | Policy missing or too restrictive | Add permissive policy or test with service_role |
| Data missing right after a region migration | Wait 15-20 min, then refresh | Stale metadata cache | Usually self-resolves; force session refresh |
| Specific rows gone, rest intact | Application soft-delete columns | App deleted rows, not Supabase | Query without deleted_at or is_deleted filter |
| Entire project locked or inaccessible | Project status in dashboard | Free-tier project paused | Upgrade plan or follow the paused-project recovery guide |
| Storage files missing, table metadata intact | Query storage.objects directly | Storage is not in the native Postgres backup | Restore from off-site backup if one exists |
| All rows gone from a table | Supabase logs, pg_stat_activity | Destructive query run against wrong project | Contact support with a timestamp |
Work through this table from the top. The first row that matches your situation is where to spend the next five minutes.
Is it a region or migration artifact?
If you recently migrated your Supabase project to a different region, or if a plan upgrade triggered a region change, the dashboard can show stale metadata for a short window.
Migration artifacts can show stale metadata for up to 20 minutes after a region change. If your project was recently moved, wait it out before escalating. Log out and back in to force a full session refresh rather than just reloading the page.
If the metadata is still wrong after 30 minutes, a stale cache is not your problem.
Is it an RLS policy hiding your data?
Row Level Security is one of the most powerful features in Supabase and one of the most common reasons data appears to vanish.
When RLS is enabled on a table, queries made through the anon or authenticated roles only see rows that match the active policies. If a policy is missing, too narrow, or incorrectly written, your application returns zero rows even though the data is there and intact.
RLS policies can make data look deleted when it is actually just hidden from the current role. Switch to the service_role key on the server side (never expose it client-side) to query without RLS filters, and confirm whether the rows actually exist.
To diagnose RLS in the SQL editor:
-- Check if RLS is enabled on your table
SELECT relname, relrowsecurity
FROM pg_class
WHERE relname = 'your_table';
-- List current policies
SELECT policyname, cmd, roles, qual
FROM pg_policies
WHERE tablename = 'your_table';
-- Count rows as the postgres superuser (bypasses RLS)
SET ROLE postgres;
SELECT count(*) FROM your_table;
RESET ROLE;
If relrowsecurity is true and the policy list is empty, that is your answer. No policy means no rows for the anon and authenticated roles. Add the appropriate policy for your use case and your data comes back immediately.
Is your Supabase data actually gone?
If RLS is not the issue and you have ruled out a migration artifact, you are dealing with one of two situations: the rows were deleted by your application, or they were deleted by a destructive query against the wrong target.
For application-level deletes: check your application logs for DELETE or UPDATE queries around the time the data disappeared. Also check whether your schema uses soft deletes. A row with a deleted_at timestamp is still in the table:
-- Find soft-deleted rows
SELECT * FROM your_table
WHERE deleted_at IS NOT NULL
ORDER BY deleted_at DESC
LIMIT 50;
For destructive queries: open the Supabase Logs panel in your project dashboard, navigate to Postgres logs, and filter by time window. If a DELETE or TRUNCATE appears there, you have a timestamp to give to support and a window for potential recovery.
If your project is on the free plan, Supabase takes no automatic backups. There may be nothing to recover. If you are on Pro or higher, keep reading.
What's recoverable (and what isn't)
What Supabase can restore depends entirely on your plan and whether you have external backups.
Supabase's native backup is a physical Postgres volume snapshot. Pro gives you 7 days of daily snapshots, Team gives 14, Enterprise gives 30. Free gets nothing. Read how Supabase's native backup works for the full breakdown of what the snapshot covers and what the retention windows actually mean in a recovery scenario.
Two gaps matter here:
Storage files are not in the native backup. The storage.objects metadata table is backed up (it is a Postgres table), but the actual file bytes in the S3 backend are not. If your Storage files are gone and you have no off-site copy, they are not recoverable from Supabase's own backup. What Supabase's native backup doesn't cover walks through this in detail.
PITR is a paid add-on, and it must be enabled before the incident. If you did not enable Point-in-Time Recovery before the deletion occurred, you cannot recover to an arbitrary timestamp. The native snapshot restores to the last daily backup, not to the moment before the destructive query ran.
If you have an off-site pg_dump backup from a tool you control, use that. You can restore it directly without going through Supabase support. The step-by-step process is in how to restore a Supabase database (coming soon).
When to contact Supabase support
Contact support when:
- Your project is on Pro, Team, or Enterprise, and you need a restore to a previous snapshot.
- You have PITR enabled and want to recover to a specific timestamp.
- You suspect data was deleted outside your application (a security incident, a compromised service_role key, or a mistake by someone on your team).
Before opening a ticket, have these ready: your project reference ID, the approximate timestamp of the deletion, and the names of the affected tables. A narrow time window speeds up the recovery significantly.
Supabase support does not guarantee data recovery for free-tier projects. Their backups documentation is explicit about what each plan includes.
How to prevent this next time
The gaps here are structural, not accidental. Free tier has no backups. Native backups are in the same AWS region as your project and cannot be downloaded. Storage is not covered. PITR must be proactively enabled. None of these defaults will change on their own.
The short checklist:
- Upgrade to at least Pro if your data has any business value.
- Enable PITR if you need the ability to restore to a specific moment, not just the last daily snapshot.
- Set up off-site Postgres backups independent of Supabase's native system. How to back up Supabase Postgres (coming soon) covers the approach: scheduled
pg_dumpexports to a storage bucket in a different region. - For Storage: build a separate off-site copy pipeline. There is no workaround on the native side.
If your project is on the free tier and was paused rather than deleted, that is a different recovery path. See how to recover a paused Supabase project (coming soon) for those specific steps.
What to do next
If you are in the middle of an incident right now: run the SQL checks above first, confirm whether RLS is hiding your data, then check your plan's backup coverage before opening a support ticket. Most of the time, data has not disappeared. It is hidden or filtered.
If you are reading this after the fact: the thing to fix is the backup posture, not the incident response. A daily pg_dump export to an object store outside of your Supabase project's region means you never have to rely on Supabase support to recover your data.
If scripting and scheduling all this yourself sounds like a second job, SimpleBackups handles Supabase Postgres, Storage, and Edge Functions backups off-site, with alerts when a run fails. See how it works →
Keep Learning
- How Supabase native backup works — to understand what the daily snapshot actually covers and what the retention window means for your recovery options.
- What Supabase native backup doesn't cover — for the full gap inventory, including why Storage files may not be in any backup.
- How to restore a Supabase database (coming soon) — for the step-by-step restore guide once you have confirmed the data is actually gone.
FAQ
Can Supabase support recover my deleted data?
Supabase support can restore from a native snapshot if your project is on the Pro, Team, or Enterprise plan. Free-tier projects have no snapshots and no recovery path through support. Recovery is only possible if the deletion occurred within your plan's retention window (7 days for Pro, 14 for Team, 30 for Enterprise), and restores are full project restores, not targeted row recoveries.
How long does Supabase keep backups after data is deleted?
The snapshot taken before the deletion stays available for the duration of your plan's retention window. Pro keeps 7 days of daily snapshots, Team keeps 14, Enterprise keeps 30. The snapshot is not deleted when rows inside it are deleted. But once the retention window expires, that snapshot is gone permanently.
Can RLS policies make my data look like it disappeared?
Yes, and this is one of the most common causes of apparently missing data. Row Level Security filters rows at query time based on the requesting role. A missing or overly restrictive policy makes tables appear empty to your application even though the rows are present. Switch to the service_role key in the SQL editor to query without RLS and confirm whether the rows exist.
What if my data disappeared after a migration?
If your project was recently moved between regions, the dashboard can show stale metadata for up to 20 minutes. Log out and back in to force a session refresh. If the data is still missing after 30 minutes, the migration is not the cause and you should work through the diagnostic checklist in the first section above.
Is there a way to check the Supabase audit log for deletions?
Supabase exposes Postgres logs under Logs > Postgres in the project dashboard. You can filter by time window and look for DELETE or TRUNCATE statements. This is not a formal audit log with user attribution, but it is usually enough to identify when a destructive query ran and from which connection or role.
How do I prevent accidental data loss on Supabase?
The most important steps: upgrade beyond the free tier (which has no backups at all), enable PITR if you need precise point-in-time recovery rather than just daily snapshots, and set up off-site pg_dump backups that you control and can restore from without going through support. Storage requires a separate backup pipeline because it is not included in the native Postgres snapshot.
This article is part of The complete guide to Supabase backup, an honest, practical reference from the team that backs up Supabase every day.