Backups and disaster recovery for Supabase apps

As of 2 October 2026, Supabase's Pro plan keeps a daily backup of your database for 7 days, the Team plan for 14 days and Enterprise for up to 30, while the Free plan has no automatic backups at all. None of these backups include the files in Supabase Storage. Point-in-time recovery is a paid add-on that lets you restore to a chosen moment, down to the second, instead of last night, from about $100 a month for 7 days of history. A backup only counts once you have restored it, so the real plan is three parts: the right backup tier, a copy you control, and a restore you have rehearsed.

This guide is for founders running an app on Supabase, including apps built in Lovable. Every platform fact below comes from Supabase's or Lovable's own documentation, checked on 2 October 2026 and listed under Sources. Prices and retention change, so check those pages before you rely on a number.

What does Supabase back up, and what does it not?

Supabase backs up your Postgres database: the tables, the data in them and the schema. That is most of what matters, but not all of it.

• Included: your tables and data and the schema. Supabase's Restore to a New Project also copies the user accounts held in Supabase Auth, with their hashed passwords.
• Not included: files uploaded through Supabase Storage. Supabase's backup documentation says database backups do not include objects stored via the Storage API.
• Not included: passwords for custom database roles you created yourself. Daily backups do not store them, so you reset them after a restore.
• Not part of the database at all: Edge Functions, API keys, auth settings and your app's code. Those live in your repository and project settings, and need their own copy.

The Storage gap surprises people most. If your app keeps invoices, photos or uploaded documents in Storage, a database restore brings back the rows that point at those files, but not the files. Supabase also notes that restoring an old backup does not bring back Storage objects deleted after it. You need a separate copy of the buckets.

How do Free, Pro and point-in-time recovery compare?

The table below summarizes Supabase's backup and pricing pages as of 2 October 2026.

Two conditions apply to point-in-time recovery. It is only available on Pro, Team and Enterprise, and the project must also run at least the Small compute add-on. Supabase lists Small at about $15 a month, while the Pro plan's compute credit covers only the $10 Micro size, so budget for the difference. Point-in-time recovery is billed by the hour, which is why the monthly figures are approximate.

The Free plan carries a second risk. Supabase's pricing page says free projects are paused after one week of inactivity. A production app should not run on a plan that can pause it.

Which backup tier does your app need?

It depends on how much data you can afford to lose, and that is a business question before it is a technical one. Two terms help. NIST defines the recovery point objective (RPO) as the point in time to which data must be recovered after an outage. The recovery time objective (RTO) is how long the system can stay in recovery before it harms the business.

In plain words: RPO is how many hours of work you can afford to lose, and RTO is how long you can afford to be down. With daily backups, a failure late in the day can cost you nearly a full day of orders, sign-ups and edits. With point-in-time recovery, the loss shrinks to minutes.

• A prototype with test data: the Free plan plus a weekly export of your own is usually enough.
• A live app with paying customers: Pro at the least, with daily backups, plus an off-site copy.
• An app where a lost hour means lost money or broken promises to customers, such as bookings, payments or orders: add point-in-time recovery.

Downtime counts too. Supabase's documentation says the project is inaccessible while it restores, and that the larger the database, the longer the downtime. Restoring in place also rolls back everything written after the backup. That is why a restore to a new project is often the safer first move: you inspect the copy, then decide what to bring back.

How are backups different for a Lovable Cloud app?

If your Lovable app runs on Lovable Cloud rather than your own Supabase project, Lovable manages the backups. As of 2 October 2026, its database documentation says:

• Lovable takes a daily backup of the project's database and keeps roughly 14 days of them.
• You restore from More, then Cloud, then Database, then Backups, to one of those daily snapshots, not to a moment in between.
• Restoring is permanent. Data created or changed after the chosen backup is lost, and the schema is reverted too, so the app may no longer match the database.
• Anyone with edit access to the project can restore.
• Backups and exports cover the database only. Files in storage buckets are not included.

The fourth point deserves attention. Anyone who can edit the project can roll back your production data, so keep that list short. If you need restores to a moment in time, a copy in your own account, or control over who can restore, the usual route is your own Supabase project. Our guide to migrating off Lovable Cloud covers what moves and what stays behind.

How do you keep a copy of your data outside Supabase?

Use the Supabase CLI. Its backup guide exports three files: the database roles, the schema and the data. The restore loads them into another database with psql in a single transaction, so a failed restore leaves nothing half-loaded. If you have added triggers or policies to Supabase's own auth or storage schemas, the guide says to restore those separately.

1. 01Export on a scheduleRun the three exports from a scheduled job, not by hand. A backup that depends on someone remembering is not a backup.
2. 02Store it somewhere elseKeep the files in storage owned by your company, under a different account from the app. A backup in the same account fails with it.
3. 03Copy the Storage bucketsSupabase's guide moves Storage objects separately, with a script that downloads each file and uploads it again. Schedule that copy too.
4. 04Encrypt and limit accessAn export holds every user's data. Encrypt it at rest and give access to as few people as possible.
5. 05Check it ranAlert when an export fails or comes back smaller than the one before. Silent failure is the common way backup jobs break.

Keep the code and schema history in GitHub as well. When every change to the database is a schema migration in the repository, you can rebuild an empty database exactly, and only the data has to come from a backup.

How do you run a restore drill?

Restore a real backup into a new, separate project and check that the app works against it. Supabase's Restore to a New Project feature does this on paid plans with physical backups, which Supabase says all projects on Postgres 15.8.1.079 and newer use. It creates an independent project from a chosen backup, or from an exact point in time if point-in-time recovery is on. Schedule a drill every quarter and after any big change to the database.

1. Pick the newest backup and restore it to a new project, never over production.
2. Check your scheduled jobs first. Supabase warns that extensions such as pg_cron and pg_net start running in the new project as soon as the restore completes, so the copy can call outside services on its own. If that is a risk, Supabase suggests a logical restore with the CLI instead.
3. Time it from start to a working app. That number is your real recovery time, not the one you hoped for.
4. Note what did not come across. Supabase lists Storage objects, Edge Functions, auth settings and API keys as not copied to the new project.
5. Point a copy of the app at it, sign in as a real test user and walk the journeys that matter most.
6. Compare row counts on your key tables with production at the time of the backup.
7. Delete the drill project afterwards. Supabase notes that restored projects are independent and billed separately.

Write the steps down as you go, with the person responsible for each. During a real outage nobody should be reading the documentation for the first time. That written runbook is the core of incident response for data loss.

What causes data loss in Supabase apps?

Backups cover a platform failure, but the causes you can control are changes made by your team or by an AI tool:

• A schema change that drops or rewrites a column, released together with the code so nobody reviews it on its own.
• A prompt in an AI builder that rewrites a table, run straight against the production database.
• A bulk update or delete without a filter, from a script, an admin screen or an SQL editor.
• Missing access rules, so one user can change or delete another user's data.
• A key with full access leaked in the browser or a public repository.

Backups fix the result. Releases can prevent the cause. On Looph, a customer-feedback product our engineers took from Lovable to production, database migrations never ride along with a deploy: they are applied by a separate, deliberate step, and a full staging copy with its own database comes first. The Looph case study describes the rest of that setup. Our guide to taking a Lovable app to production covers the same release discipline for any Lovable app.

What should a Supabase disaster recovery checklist include?

• A written RPO and RTO for the app, agreed with whoever answers to customers.
• A paid plan for any app with real users, and point-in-time recovery where losing a day of data is not acceptable.
• A scheduled off-site export of the database, in an account you own.
• A separate scheduled copy of every Storage bucket.
• Every schema change in version control, reviewed, and applied on its own.
• A short list of people who can restore, and a record of who did.
• A restore drill every quarter, timed, with the runbook updated after each one.

Plans start at $2,999 a month paid annually, or $3,999 month to month; see pricing. To see where your app stands today, take the free production-readiness check: 19 questions, a score out of 100 and your three biggest risks.

Sources

Each platform fact above comes from one of these pages, checked on 2 October 2026.

• Supabase documentation: Database Backups (supabase.com/docs/guides/platform/backups).
• Supabase pricing (supabase.com/pricing).
• Supabase documentation: Restore to a New Project (supabase.com/docs/guides/platform/clone-project).
• Supabase documentation: Compute and Disk, for the Micro and Small compute prices (supabase.com/docs/guides/platform/compute-add-ons).
• Supabase documentation: Backup and Restore using the CLI (supabase.com/docs/guides/platform/migrating-within-supabase/backup-restore).
• Supabase CLI reference: supabase db dump (supabase.com/docs/reference/cli/supabase-db-dump).
• Lovable documentation: Database (docs.lovable.dev/features/database).
• NIST glossary: Recovery Point Objective and Recovery Time Objective, from NIST SP 800-34 Rev. 1 (csrc.nist.gov).
• Case-study facts: our Looph case study, as published on this site.