How long should you keep Supabase backups?

The newest backup is not always the useful one. A bad background job can quietly damage data for days before anyone notices. By then every short-lived backup may contain the same problem.

Supabase retention by plan

At the time of writing, Supabase documents daily database backups for paid projects with plan-dependent retention: seven days on Pro, fourteen days on Team and up to thirty days on Enterprise. Free projects should export data regularly and keep it off-site. Always confirm the current values in the official Supabase backups documentation because product plans can change.

Those windows describe provider-managed database backups. They are not automatically the correct policy for your business, and they do not cover actual Storage object bytes. They also do not create independence from the Supabase project lifecycle.

Start with detection time, not storage price

Suppose a background job has been deleting the wrong tenant records for twelve days. Seven daily restore points may all be too new. Retention must exceed the longest plausible time between the start of an incident and reliable detection, plus time for investigation and recovery.

• Fast operational mistakes may need hours or days of recovery points.
• Silent application corruption may require weeks or months.
• Financial or contractual records may have longer legal retention requirements.
• Privacy rules may require deletion after a defined period, including from backups.

Separate operational and archival retention

Operational backups

Operational backups are recent and quick to restore. They support common incidents such as a bad migration or accidental delete. Daily backups and PITR belong primarily in this layer.

Independent recovery copies

These copies live outside the Supabase project lifecycle and protect against account, provider or project-level loss. Logical PostgreSQL backups are useful here because they are portable and can be restored into a clean PostgreSQL environment.

Archive copies

Archives preserve selected historical points for longer periods. They should be fewer, immutable where appropriate and subject to explicit access and deletion rules. Keeping every daily backup forever creates cost and privacy risk without necessarily improving recovery.

A practical grandfather-father-son policy

A common starting model is daily, weekly and monthly tiers. For example: retain daily copies for fourteen days, weekly copies for eight weeks and monthly copies for twelve months. This is an example, not a universal recommendation. Adjust it using incident-detection history, regulation, customer commitments, restore time and budget.

Each retained tier should include the matching database artifact, Storage manifest and object copy, plus configuration version. A year-old database without its files or application version may not be meaningfully recoverable.

Retention controls that matter

• Object lock or immutability for a defined period, balanced against required deletion workflows.
• Separate credentials for backup creation and backup deletion.
• Encryption keys whose lifecycle is at least as long as the retained backup.
• Lifecycle rules that are tested before relying on automatic expiry.
• An inventory proving which recovery points actually exist.

Test older backups too

Teams naturally test the latest backup, but long-term copies fail in different ways. Encryption keys are rotated, formats age, extensions change and runbooks drift. Sample a weekly or monthly recovery point during restore drills and record whether the current tooling can still read it.

Use our PostgreSQL backup test procedure to validate artifacts and the Supabase backup checklist for full application recovery. Retention is useful only when the retained copy remains restorable.