A backup is only as useful as the restore it makes possible, and the restore is the part almost nobody tries until the day they need it. This piece covers what Supabase provides, what it leaves out, and what a recovery process looks like for an app with paying customers.

What Supabase gives you

This is how Supabase's backup documentation describes it at the time of writing. Plans and add-ons change, so check what your own plan includes in the project dashboard before relying on any of it.

  • Free plan: no automatic backups, and Supabase's production checklist notes that backups are not available for download on Free plan projects. Supabase recommends that Free plan projects export their data regularly with the Supabase CLI and keep off-site copies.
  • Pro plan: daily backups, with the last 7 days available.
  • Team plan: daily backups, with the last 14 days available.
  • Enterprise plan: daily backups, up to 30 days.
  • Point-in-time recovery: an add-on for paid plans that allows a restore to a chosen moment, down to seconds. Supabase states a worst-case recovery point of two minutes. It requires at least the Small compute add-on.

For an app with customers, the Free plan's position is the one to take seriously. Its projects can also be paused after a week of low activity, which is fine for an experiment and uncomfortable for a business.

What those backups leave out

Files. Supabase is explicit that database backups do not include objects stored through the Storage API. The database holds the metadata about each file, not the file. A restore brings back the row that says an invoice PDF exists, without the PDF.

Passwords for custom roles. After a restore from a daily backup, custom database roles need their passwords reset. Anything that connects with one of those roles fails until someone does.

Everything outside the database. Application code lives in Git and on the host. Environment variables live on Vercel or Netlify. Edge function code, auth provider settings, DNS and third-party webhooks all live somewhere else, and none of them are in a database backup.

A rollback is not a restore

Vercel's Instant Rollback and Netlify's option to publish a previous deploy are excellent, and both are close to instant. Both roll back code, not data. Vercel's rollback dialog includes a reminder about external databases for exactly this reason.

So the common incident goes like this.

A release includes a migration.

The migration was reviewed. It ran cleanly in development.

Development had eleven rows.

Production has all of them, and the migration drops a column the new code no longer needs and the old code very much does.

Someone rolls back the deploy. The old code comes back instantly and asks for a column that no longer exists.

The dashboard reports that the rollback was successful. Technically, it was.

What a recovery process looks like

Decide what you can afford to lose

Two numbers, in plain terms. How much data can the business lose: a day, an hour, a few minutes? And how long can the app be down while it is restored? Daily backups mean up to a day of lost writes. If that is not acceptable, point-in-time recovery is the answer on Supabase, and the cost of the add-on is worth comparing with the cost of a day of lost orders.

Keep a copy outside the platform

Platform backups protect against most failures. They do not protect against losing access to the account, a billing problem, or a mistake made with the same credentials that control the backups. A scheduled export to storage you control, in a separate account, covers those. Supabase documents doing this with its CLI:

supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only -x "storage.buckets_vectors" -x "storage.vector_indexes"

The connection string is a secret. It belongs in the scheduler's secret store, never in the repository.

Back up Storage separately

Files in Supabase Storage need their own copy, on their own schedule, ideally in the same place as the database exports so that a restore brings back both halves together.

Restore somewhere other than production

Supabase makes a project inaccessible while it is being restored, and a restore over the live project replaces what is there. Restoring into a separate project first, which Supabase supports, lets you check the data and pull back only what was lost, without taking the app down to find out whether the backup is any good.

Test it, then write it down

A restore that has been done once, recently, by someone following written steps, is a recovery process. Everything short of that is a hope. The written steps should include the parts people forget under pressure: resetting custom role passwords, pointing the app at the restored database, restoring Storage, and checking that sign-in still works.

Get told when a backup fails

A scheduled export that has quietly failed for three months produces an off-site copy that is three months old, and nobody finds out until the day it is needed. The job needs an alert that reaches a person when it does not complete.

Backups are cheap. Restores are where the cost lives: the downtime, the missing files, the role nobody remembered. The only way to know that cost in advance is to pay a small version of it on purpose.

Where we come in

When we take on production for an AI-built app, backups and recovery are part of the work from the first week: checking what the plan provides, adding the off-platform copy and the Storage backup, testing a restore into a separate project, and writing the runbook our on-call engineers follow. When something does go wrong, the restore is run by someone who has done it before on that app.

Production support for AI-built apps explains the full service, which covers monitoring, incident response and security review as well. It is delivered through Critical Support Lite or Critical Response, depending on the cover you need.