Supabase Backup Retention: How Long Are Backups Kept?
How long does Supabase keep your database backups?
As of 2026, Supabase’s standard daily backup retention depends on your plan:
| Supabase Plan | Automatic Daily Backups | Backup History |
|---|---|---|
| Free | No standard daily backup history | — |
| Pro | Yes | 7 days |
| Team | Yes | 14 days |
| Enterprise | Yes | Up to 30 days |
Supabase automatically backs up Pro, Team, and Enterprise projects daily. Free Plan users are instead advised to regularly create database exports with supabase db dump and maintain off-site backups.
That sounds straightforward, but backup retention has some important limitations.
A 7-day backup history does not mean your data is protected indefinitely. It means that as newer backups are created, older recovery points eventually fall outside the available retention window.
Let’s look at exactly how Supabase backup retention works and when an additional backup strategy makes sense.
What Does Backup Retention Mean?
Backup retention is how long a backup remains available for recovery.
Suppose your Supabase Pro project creates one database backup each day and keeps seven days of backup history.
A simplified example might look like:
Monday ✓
Tuesday ✓
Wednesday ✓
Thursday ✓
Friday ✓
Saturday ✓
Sunday ✓When another backup is created, an older backup eventually falls outside the seven-day retention window.
This means backup frequency and backup retention are different.
Backup frequency: How often a backup is created.
Backup retention: How long recovery points remain available.
Both matter.
A daily backup with seven days of retention gives you very different recovery options from daily backups retained for several months.
Supabase Pro Backup Retention
Supabase Pro projects currently receive:
Daily automatic backups with access to the previous 7 days of backup history.
For many small SaaS applications, seven days can provide useful protection against recent problems such as:
- An incorrect database migration
- Accidental data deletion
- Application bugs that modify records
- A bad import
- Developer mistakes
- Recent database corruption
Imagine you discover on Friday that something went wrong on Wednesday.
A recent backup may still give you a useful recovery point.
But consider a different situation.
An unnoticed bug began deleting older records three weeks ago.
If your available backup history only reaches back seven days, every remaining backup may already contain the problem.
This is why the appropriate retention period depends partly on how quickly you are likely to discover data problems.
Supabase Team Backup Retention
Supabase Team projects currently receive:
14 days of daily backup history.
That doubles the standard recovery history available on Pro.
For teams maintaining production applications, the additional history can be useful because many database problems are not discovered immediately.
For example:
Day 1 → Bug introduced
Day 4 → Incorrect data starts accumulating
Day 10 → Customer reports problem
Day 11 → Engineering investigatesWith seven days of history, your clean recovery point may already be gone.
With fourteen days, you may still have more options.
That does not automatically mean every Team project needs to restore an old backup. It simply gives the team a longer window from which to investigate potential recovery points.
Supabase Enterprise Backup Retention
Supabase Enterprise projects can access up to 30 days of daily backup history.
A longer retention period is particularly useful when:
- Problems may remain unnoticed for weeks
- Applications contain important business data
- Multiple teams modify production systems
- Recovery requirements are stricter
- Customers depend heavily on historical data
However, even 30 days is still a defined retention period.
If you need database copies from six months ago or one year ago, standard daily backup retention alone is not designed to provide that kind of archival history.
You would need a separate long-term backup strategy.
Does Supabase Free Include Automatic Daily Backups?
Free Plan projects do not receive the same standard automatic daily backup history available to paid projects.
Supabase specifically recommends that Free Plan users periodically export their database using:
supabase db dumpand maintain backups outside the platform.
For a prototype with disposable data, this may not seem important.
But once real users begin creating important records, relying on the database without an independent backup becomes increasingly risky.
A simple Free Plan workflow could be:
Supabase Database
↓
Weekly logical backup
↓
Off-site storageThe important part is consistency.
A backup you intended to create but forgot about does not protect anything.
What Happens When a Supabase Backup Expires?
Once a backup falls outside the available retention window, you should not expect it to remain available as a normal recovery point.
For example, with seven days of backup history:
Today
↓
Day -1 ✓
Day -2 ✓
Day -3 ✓
Day -4 ✓
Day -5 ✓
Day -6 ✓
Day -7 ✓
Older recovery point → outside normal retentionThis is why you should not think of native backup history as permanent archival storage.
It is primarily a recent recovery system.
If you need older database snapshots for:
- Long-term disaster recovery
- Auditing
- Historical reference
- Migration protection
- Customer requirements
consider maintaining separate backups with your own retention rules.
What About Supabase Point-in-Time Recovery?
Point-in-Time Recovery, or PITR, provides a more precise recovery mechanism than standard daily backups.
Instead of selecting only from daily backup snapshots, PITR lets you restore to a selected point within your available recovery window with fine-grained time selection.
Supabase currently offers PITR retention options of:
| PITR Recovery Window | Approximate Monthly Price |
|---|---|
| 7 days | ~$100 |
| 14 days | ~$200 |
| 28 days | ~$400 |
These charges are per project and are in addition to the underlying Supabase plan and applicable compute costs.
PITR becomes valuable when losing even several hours of data would be expensive.
For example:
09:00 Normal database activity
11:42 Bad query runs
11:44 Problem discoveredA daily backup may require restoring to yesterday.
PITR may allow you to select a recovery point immediately before the destructive event, provided that point is within your configured retention window.
Daily Backups vs PITR Retention
These two features should not be confused.
| Feature | Daily Backups | PITR |
|---|---|---|
| Recovery points | Daily snapshots | Fine-grained points in time |
| Pro retention | 7 days | Configurable |
| Team retention | 14 days | Configurable |
| Enterprise retention | Up to 30 days | Configurable |
| Best for | General recovery | Precise production recovery |
| Additional PITR charge | No | Yes |
For a small application, daily backups may be enough.
For a high-activity production database where losing a day’s transactions would be unacceptable, PITR may be more appropriate.
Does Deleting a Supabase Project Keep Its Backups?
No.
This is one of the most important limitations to understand.
The 7-, 14-, or 30-day retention periods do not mean your backups remain available after you permanently delete the project.
Supabase states that deleting a project permanently removes its associated data, including backups.
So this assumption is incorrect:
Delete project
↓
Wait
↓
Restore from 7-day backupInstead:
Delete project
↓
Project + associated backups removedIf protection against accidental project deletion matters to you, an independent backup outside that project becomes much more valuable.
Native Retention vs Off-Site Backup Retention
Supabase’s native backups answer:
How far back can Supabase restore this active project?
An independent backup answers a different question:
How long do I want to keep copies of my database outside the project’s native backup system?
Those can have very different retention policies.
For example:
Supabase Pro
Native history: 7 days
Independent backups
Daily: 30 backups
Monthly archive: longer if neededThere is nothing inherently wrong with seven days of native retention.
The question is whether seven days matches your recovery needs.
How Much Backup History Do You Actually Need?
There is no universal number.
Consider three questions.
How quickly would you notice a problem?
If database errors are normally discovered within hours, shorter retention may be acceptable.
If incorrect data could remain unnoticed for weeks, longer retention becomes much more important.
How valuable is your data?
A personal test project and a SaaS application containing customer records do not carry the same recovery risk.
As your application grows, your backup strategy should usually grow with it.
How much data can you afford to lose?
This is often called your Recovery Point Objective (RPO).
If losing up to one day of data is acceptable, daily backups may be sufficient.
If losing even one hour creates serious business problems, you should investigate more frequent recovery options such as PITR.
Should You Keep an Independent Supabase Backup?
For important projects, it can be useful.
Supabase’s native backups are extremely convenient for managed recovery.
An external logical backup gives you a different recovery layer.
A simple setup could look like:
Supabase Database
│
┌──────────┴──────────┐
↓ ↓
Native Backups Independent Backup
↓ ↓
Supabase Restore Off-site Copy
The goal is not necessarily to replace Supabase backups.
It is to avoid making every recovery scenario depend on exactly the same backup system.
Extending Retention With SupaBackup
If you want independent Supabase database backups without maintaining your own scheduled scripts, SupaBackup can save automated database backups directly to your connected Google Drive.
The current Pro plan supports:
- Daily backups
- Up to 3 backup jobs
- Keeping the latest 7 backups
- Keeping the latest 14 backups
- Keeping the latest 30 backups
- Or disabling automatic deletion and keeping all generated backups
The backup files are stored in the Google Drive account you connect rather than being permanently stored by SupaBackup.
Notice an important distinction:
SupaBackup retention is based on the number of backups kept, not simply a fixed Supabase plan recovery window.
With daily backups:
Latest 7 backups ≈ roughly one week
Latest 14 backups ≈ roughly two weeks
Latest 30 backups ≈ roughly one monthIf you choose to keep everything, your actual retention then depends on how long you choose to preserve those files in Google Drive.
This can be useful when you want more direct control over your independent backup history.
Supabase Retention vs SupaBackup Retention
They solve different problems.
| Feature | Supabase Native Backups | SupaBackup |
|---|---|---|
| Primary purpose | Managed recovery | Independent off-site copy |
| Backup destination | Supabase infrastructure | Your Google Drive |
| Pro history | 7 days | Not tied to Supabase Pro retention |
| Team history | 14 days | Not tied to Supabase Team retention |
| Retention control | Plan-dependent | Latest 7, 14, 30 or keep all on Pro |
| Project deletion protection | Associated backups are deleted | Existing Drive copies remain separate |
| Best used as | Primary managed recovery | Additional backup layer |
You do not necessarily need to choose one.
For a production application, using native recovery plus an independent backup can provide more flexibility.
A Simple Backup Retention Strategy
For a small Supabase SaaS application, a practical starting point might be:
Supabase native backups
+
Daily independent backups
+
Keep at least 14–30 recent copies
+
Manual backup before major migrations
+
Occasional restore testingThis is not a universal requirement.
A low-risk side project may need much less.
A business-critical application may need significantly more, including PITR, longer archival retention, monitoring, and formal disaster-recovery procedures.
The goal is to decide intentionally rather than discovering your retention limit during an emergency.
Final Takeaway
Supabase’s standard backup retention in 2026 is simple:
Pro: 7 days
Team: 14 days
Enterprise: up to 30 days
Those backups are valuable for recent managed recovery, but they are not permanent archives.
If the available recovery window matches your application’s risk, native backups may be enough.
If you need longer history, an independent copy, or protection from scenarios such as permanent project deletion, add an off-site backup strategy.
SupaBackup can automate that additional layer by saving scheduled Supabase database backups directly to your Google Drive, where you control how long those copies remain available.
