Why every Supabase project needs its own backups

The Hard Truth About Supabase Backups

Supabase provides daily backups for Pro, Team, and Enterprise plans. That's a good safety net. But it's their safety net, not yours.

Here's what Supabase's own documentation says:

• Pro Plan: 7 days of daily backups
• Team Plan: 14 days of daily backups
• Enterprise Plan: Up to 30 days of daily backups
• Free Plan: No backups at all — Supabase recommends using the CLI db dump command

And critically: "Database backups do not include objects you store via the Storage API." Your users' uploaded files, images, and documents are not in the backup.

Source: [Supabase Docs — Database Backups](https://supabase.com/docs/guides/platform/backups)

What Supabase Backups Cover (And What They Don't)

If you're on the free tier, you have zero automated backups. If you're on Pro, you have 7 days — but no storage objects, no edge functions, and no custom role passwords.

The 3 Risks of Relying Only on Platform Backups

Risk Level by Scenario

Platform backup only     ████████░░░░░░░░  HIGH RISK
Own off-site backup      ██░░░░░░░░░░░░░░  LOW RISK
Both (defense in depth)  █░░░░░░░░░░░░░░░  MINIMAL RISK

1. Vendor Deletion Is Irreversible

Supabase's documentation is explicit: "When you delete a project, we permanently remove all associated data, including any backups stored in S3. This action is irreversible."

If someone accidentally deletes your project — a misclick, a compromised account, a billing lapse — your database AND all platform backups are gone. There is no undo.

2. Ransomware Targets Backups First

According to Veeam's 2024 research, 96% of ransomware attacks now explicitly target backup repositories. If your only backup lives in the same infrastructure as your production database, one compromised credential can wipe everything — production data and backups together.

Source: [Veeam — 3-2-1 Backup Rule](https://www.veeam.com/blog/321-backup-rule.html)

3. No Storage Objects Means Missing Files

Your database backup contains metadata about storage objects (file paths, sizes, bucket names) but not the files themselves. If you restore from a Supabase backup, your database tables come back — but every file your users uploaded is gone. Profile photos, documents, PDFs — all missing.

Source: [SimpleBackups — Supabase Backup Tools Comparison](https://simplebackups.com/blog/best-supabase-backup-tools)

Real-World Disasters That Prove the Point

The February 2026 Supabase Outage

In February 2026, Supabase experienced an outage in their us-east-2 region. Projects in that region were inaccessible. If your only backup lived in that same region, you had no recovery option until the platform came back online. Teams with off-site backups could have restored to a different region or a local database and kept serving users.

Source: [Supabase — Incident on February 12, 2026](https://supabase.com/blog/supabase-incident-on-february-12-2026)

The AI Agent That Wiped a Production Database

In 2026, a developer gave an AI coding agent (Claude Opus) unsupervised database access. Within ten minutes, the agent executed a destructive query that wiped the entire production database. The developer had no off-site backup. The incident went viral on Reddit and served as a wake-up call for the entire community.

This is the new face of human error. It's not just a typo in a SQL query — it's an AI tool with database credentials running a command you didn't review.

Source: [Reddit — Claude AI agent deletes entire production database](https://www.reddit.com/r/ClaudeAI/comments/1sxe7cf/claudepowered_ai_coding_agent_deletes_entire/)

The Moltbook Misconfiguration

Moltbook, an AI social network, had a misconfigured Supabase database that exposed 1.5 million API keys, private messages, and user emails. The data was accessible to anyone who found the exposed database URL. No ransomware, no sophisticated attack — just a misconfiguration.

Backups wouldn't have prevented the exposure, but they would have allowed the team to quickly audit what was exposed, restore a clean state, and recover from any data corruption that resulted from the incident.

Source: [Wiz — Hacking Moltbook: AI Social Network Reveals 1.5M API Keys](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)

Slow-Burn Disasters: The Silent Killer

Not all data loss is dramatic. The most dangerous type is the slow-burn disaster — a subtle bug that corrupts data over weeks or months. A migration script with an off-by-one error. A schema change that silently drops a column. An ORM update that changes how nulls are handled.

By the time you notice, your Supabase platform backups only go back 7-30 days. The corruption happened months ago. Platform backups can't save you because they're also corrupted.

This is why independent, long-retention backups matter. If you keep monthly snapshots for 6 months, you can reach back to a known-good state before the corruption started.

Source: [SimpleBackups — What Supabase's Native Backup Doesn't Cover](https://simplebackups.com/blog/what-supabase-native-backup-doesnt-cover)

The 3-2-1 Rule: What It Means for Supabase

The 3-2-1 backup rule is the gold standard for data protection:

3 copies    →  Production + 2 backups
2 media     →  Different storage types (e.g., cloud DB + Google Drive)
1 off-site  →  Different vendor/region than production

For Supabase projects, this means:

1. 1Your live Supabase database (production)
2. 2Supabase's built-in daily backups (same vendor, same region)
3. 3Your own off-site backup in Google Drive (different vendor, different region)

Supabase's built-in backups give you copy #2 — but it's same-vendor, same-region. You need copy #3 to satisfy the 3-2-1 rule.

Source: [Acronis — 3-2-1 Backup Strategy](https://www.acronis.com/en/blog/posts/backup-rule/), [US Chamber — 3-2-1 Backup Rule](https://www.uschamber.com/co/run/technology/3-2-1-backup-rule)

How Supakeep Fills the Gap

Supakeep automates the off-site copy that Supabase's built-in backups don't provide:

Supabase DB  ──→  Supakeep (stream)  ──→  Your Google Drive
   (production)      (zero retention)       (your storage)

• Database + storage + auth + edge functions backed up
• Lands in YOUR Google Drive — different vendor, different region
• Zero-retention: Supakeep never stores your data
• 20-second setup via OAuth

Related reading: Supabase backup best practices for small teams and backups vs. replication: what's the difference?.