What Supabase backups cover and what they do not

Supabase's built-in backups run without extra setup and paid projects should keep them enabled. They protect the database inside Supabase. This guide covers the parts that sit outside that backup.

What the built-in backups cover

Per the official backups guide, paid projects get daily automated database backups: 7 days of retention on Pro, 14 on Team, up to 30 on Enterprise. Restores run from the dashboard, and the PITR add-on narrows the recovery point from "last night" to "seconds before the incident". Free projects get no automated backups at all. Only manual CLI dumps.

For a bad migration or accidental database change caught within the retention window, the built-in restore is usually the fastest option.

What they do not cover

Storage files are not in the backup

Supabase is explicit that database backups do not include the objects stored via the Storage API. The database contains their metadata, so a restored project can contain object rows without the corresponding files. See do Supabase backups include Storage?.

The backups live inside the project they protect

Deleting a project permanently removes its backups with it, irreversibly. A compromised account can create the same risk if an attacker can delete the project. An independent copy covers that wider failure boundary.

Newer projects cannot download their backups

Projects on recent Postgres versions use physical backups, which are not available for direct download. Your recovery point exists, but it is not portable: you cannot take it to another provider, another region, or a local machine without generating a separate logical dump yourself.

Retention stops at your plan

Seven days on Pro means a problem discovered later can fall outside the available restore window. Choose retention from likely detection time, not only backup frequency.

A completed backup is not a restore test

The dashboard shows that a backup exists, but it does not provide a per-backup report showing a restore, row-count comparison or application test.

What an independent layer adds

ReviveDB stores the database and Auth state, Storage file bytes, Edge Function bundles and supported configuration outside the Supabase account. The database in every run is restored into a scratch database and compared against the source inventory. It checks structure, row counts, sequences and extensions before the database is marked restore-tested. Storage files and Edge Function bundles are checked separately by hash. Retention runs to 30 or 60 days on paid plans, and the free tier keeps one project on weekly recovery points.

When to keep both

Native backups and an independent copy answer different failure questions:

• Keep native backups and PITR for fast, precise rollback inside a healthy project.
• Keep an independent checked copy for everything the platform cannot cover about itself: account-level failure, Storage bytes, portability, longer retention, and database restore evidence.

If you are choosing between the database options themselves, our daily backups vs PITR guide walks through RPO and RTO. Whichever you pick there, the question this post answers stays the same: the built-in backup protects your database inside Supabase. Something still has to protect your project from everything else.