Supabase Backup in 2026: Plans, Limits, and a Restore Drill

Supabase’s free plan has no automatic backups. Pro keeps a rolling 7 days of daily database backups, Team keeps 14, and Enterprise can access up to 30. No plan’s database backup includes Storage files. Point-in-time recovery (PITR) adds up-to-seconds recovery from about $100 a month on top.

The rest of this post covers the four ways to back up a Supabase database, how to copy the Storage buckets that no database backup touches, and how to prove a restore actually works.

Does the Supabase free plan include automatic database backups?

No. There is no platform-managed backup on the free plan that you can restore from. As checked on 16 August 2026, Pro ($25/mo) keeps a rolling seven days of daily database backups, Team keeps fourteen, and Enterprise can access up to thirty. The PITR add-on replaces the daily snapshot with continuous recovery at up-to-seconds granularity. No tier’s database backup includes Storage files, only their metadata. Supabase documents the plan windows and exclusions in its database backup guide, while current base prices live on the Supabase pricing page.

Physical backups vs logical backups

Physical backups are Postgres-level snapshots plus Write Ahead Log (WAL) archiving, handled by the open-source tool WAL-G. Supabase’s docs state that all projects on Postgres 15.8.1.079 and newer use the physical backup process, while older projects get logical backups, which are pg_dump output. The distinction decides what the platform can sell you: PITR is built on WAL archiving, so it belongs to the physical path, and every do-it-yourself route in this post produces a logical dump.

What each row of the plan table means once you try to use it:

Every row above is doing real work, and every row also has an edge that the settings page doesn’t state out loud. The backup gap is one of four conveniences that come due after launch; why everyone uses Supabase, and what the free tier really covers prices the other three. And if you are comparing hosts on what backups actually cost rather than what they advertise, what the Supabase alternatives cost you in backups puts the same plan-tier question to each of them.

A Supabase backup on a paid plan gives you a documented recovery point. Whether that recovery point can recreate the parts of your app that matter is a separate fact, and the settings page cannot answer it for you. An untested restore was a recurring data-safety gap in the apps I audited.

Measured across 20 of the 21 third-party apps in the June and July 2026 audit corpus, the Data Integrity & Safety pillar averaged 51.6 out of 100. That number covers several classes of failure, so it does not prove that any particular backup will fail. It does explain why a restore drill belongs beside the backup toggle rather than being inferred from it.

None of what follows is a criticism of Supabase’s backup system. It works as documented, the same way the platform half of whether Supabase is safe holds up under its own audits. The gap sits between what the settings page shows and what a founder assumes it means about backing up a Supabase database with real users on it, and closing that gap takes about as long as reading this post.

How to back up a Supabase database: four methods

There are four routes, and most projects end up using two of them. Ordered by effort:

1. The dashboard daily backup, on Pro and above. Nothing to set up. It runs once a day, holds the window your plan pays for (7, 14, or up to 30 days), and covers the database only.
2. Point-in-time recovery, a paid add-on on top of a paid plan. Continuous WAL archiving instead of a nightly snapshot, so you can pick a moment rather than a day. What it costs and when it earns that.
3. A Supabase CLI logical dump, available on every plan including free. Three commands, run on a schedule you own, stored off-site. This is the only real backup a free-plan project has. The three-part dump.
4. Downloading the backup file and restoring it locally, which is for inspecting a backup or extracting rows. Restoring service after the hosted window uses the new-project migration path below. The local restore procedure.

None of the four backs up Storage buckets. That is a separate job, covered below.

Paid third-party backup services sit on top of this list, and they exist for a real reason: they bundle the database dump, the Storage bucket copy, off-site retention and failure alerting into one scheduled job instead of four things you maintain. Buying one is the right call when nobody on the team wants to own a cron job, when you need retention longer than your plan’s window without paying for PITR, or when Storage buckets hold data you cannot regenerate. It is the wrong call if you have not yet run a restore drill, because a second untested backup is not twice the safety.

What “backups are on” doesn’t cover

Three gaps sit underneath Supabase’s green backup toggle: Storage files are never in the database backup, the rolling seven-day window silently ages out anything older, and deleting the project deletes every backup with it. Each one lives on a different page of Supabase’s own docs, so checking the settings screen once catches none of them.

Storage files are not in the database backup

This holds on every plan. Supabase’s own documentation is direct about it: “database backups do not include objects you store via the Storage API, as the database only includes metadata about these objects.” Restore a database backup after losing a bucket and its metadata can return without the underlying bytes. An app that stores avatars, PDFs, or user uploads in a bucket needs a second, separate copy of those files. A successful database restore therefore does not prove that file downloads work.

The seven-day window only ever holds seven days

A daily backup on Pro ages out the moment an eighth one lands, so nothing before the current seven-day window is recoverable no matter when someone looks for it. A bad migration, a bug, or a bulk update that corrupts rows can sit unnoticed for longer than that during a quiet launch week, and by the time anyone checks, the backup that would have undone it is already gone.

Deleting the project deletes the backups with it

Supabase’s docs put this plainly: on deletion, “we permanently remove all associated data, including any backups stored in S3. This action is irreversible.” Pausing a project for nonpayment or inactivity and later deleting it to start fresh takes the safety net down with it. There’s no separate “keep the backups” option once the project itself is gone.

A backup that has never produced a working restore is a setting, not a safety net.

Supabase free tier backups: a three-part off-site dump

The free plan’s answer to “no automatic backups” is to create an off-site logical backup yourself. Supabase’s backup-and-restore procedure recommends its CLI db dump flow, which wraps pg_dump and requires the Supabase CLI and Docker. Use a URL-encoded database connection string from the project’s Connect panel. The connection guide says to choose the direct connection when the runner has IPv6 connectivity, or the Supavisor session pooler on port 5432 when it does not. Use a session connection for backup and restore work, not transaction mode on port 6543.

supabase db dump --db-url "$SUPABASE_DB_URL" \
  --file "roles-$(date +%F).sql" --role-only
supabase db dump --db-url "$SUPABASE_DB_URL" \
  --file "schema-$(date +%F).sql"
supabase db dump --db-url "$SUPABASE_DB_URL" \
  --file "data-$(date +%F).sql" --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"

The three files matter: the default supabase db dump contains schema but no table data or custom roles. Store the full connection string as a protected secret, encrypt the outputs, and send them to access-controlled object storage with a retention policy. The CLI also excludes Supabase-managed schemas from its normal dump boundary, while Storage object bytes still require a separate export or sync. Restoring these files back into a target project is a psql job (or pg_restore if you dump in custom format), following Supabase’s restore guide. Test that restore from the stored artifacts at least once, because a dump nobody has replayed is a file, not a backup. This path recovers only to the latest successful dump, never to an arbitrary second.

Scheduling the dump

GitHub Actions is the cheapest runner for this. Put the workflow at .github/workflows/backup.yml, schedule it with cron: '0 3 * * *' for a nightly run, and store the connection string as an encrypted repository secret rather than a literal in the file. Hosted CI runners often have no IPv6 address, so use the Supavisor session pooler on port 5432 unless you have confirmed the runner can reach the direct connection. Alert on job failure, because a backup workflow that has been red for three weeks is worse than no workflow at all: it produces the belief without the file.

Do not commit the dump files back into the repository. That is the pattern most free-plan tutorials teach, and it is the wrong one. Git history can be rewritten, so a later cleanup can remove the dump from the branch you control. It cannot recall existing clones, forks, caches, or copies made before the rewrite. GitHub’s sensitive-data guidance starts with rotating or revoking the exposed secret, then treats history rewriting as a separate cleanup. A private repo is also one added collaborator away from being a plaintext copy of your users table, and the copy travels to every laptop that clones it. Push the encrypted artifacts to object storage with a lifecycle rule instead, and let the repo hold only the workflow.

How to back up Supabase Storage buckets

Storage needs its own job, and Supabase gives you a standard way to run one: the S3-compatible endpoint. Turn it on and copy buckets with the same tools you would use against any object store.

1. 01 Enable the S3 connection in the project settings Storage section, then generate S3 credentials only for a trusted server. Generated keys can perform every S3 operation across every bucket and bypass row level security.
2. 02 Copy the endpoint and region from the same S3 configuration page. The endpoint takes the form https://<project-ref>.storage.supabase.co/storage/v1/s3.
3. 03 Point an S3-compatible client at it. The aws s3 sync command and rclone both work, because both read standard AWS credentials and accept a custom endpoint.
4. 04 Sync each bucket to off-site storage on the same schedule as the database dump, so the two copies describe the same moment.
5. 05 Export bucket configuration separately. Bucket names, public or private status, file size and MIME limits, and the row level security policies on storage.objects are settings, not objects, so no file sync captures them.
6. 06 Restore-test the pair together: put the database dump into a target project, sync the files back, and open a URL that serves a real upload.

Supabase documents the credential and endpoint setup in its S3 authentication guide. Generated access keys and secret keys are server-only credentials with full access to every S3 operation and bucket in the project. They bypass row level security. A JWT-based session token is the separate option when access should follow a user’s RLS policies. The reason this section exists at all is that the metadata rows and the bytes live in two different systems, so restoring one without the other gives you a table full of file paths pointing at nothing.

The restore drill, timed

A backup is a claim. The only way to check it is to spend it once, somewhere that doesn’t matter, before the day it does. Supabase’s Restore to a New Project guide defines the clone behavior and exclusions used in this drill. The backend-agnostic version of the same procedure is in test your backups: a restore drill for any backend, which is the one to use if Supabase is not the only datastore you would have to bring back.

1. 01 Clear the prerequisites first. If the project uses logical replication subscriptions or replication slots, Supabase requires you to drop them before the restoration and recreate them afterwards. Note the source project's Postgres version at the same time, since 15.8.1.079 and newer use physical backups and older projects use logical ones.
2. 02 Open Database > Backups in the source project, then choose Restore to a New Project. Do not create the destination first: this flow creates it for you.
3. 03 Choose the newest useful physical backup or a PITR timestamp and review the displayed cost. The clone mirrors source compute and disk attributes, stays in the same region, and creates another billable project.
4. 04 Record the start time and wait for the new project to appear. The source remains your production project; this drill avoids an in-place restore and its downtime.
5. 05 Immediately disable or review extensions that can call external systems, including pg_cron, pg_net, and wrappers, so the clone cannot repeat production jobs.
6. 06 Record the finish time, then compare row counts and a few known records in the tables the business cannot lose.
7. 07 Check Auth users, roles, functions, indexes, and encrypted values. Reset custom Postgres role passwords because daily backups do not retain them.
8. 08 Check every excluded surface separately: Storage objects and bucket settings, Edge Functions, Auth settings and API keys, Realtime settings, read replicas, and project-level configuration are not recreated as a complete app.
9. 09 Delete the billable clone after recording the restore time, the missing surfaces, the checks that passed, and the steps required to make the restored project usable.

That is an afternoon of work and a temporary project charge. The useful output is a measured restore time plus an explicit list of what the database clone did not recreate. Those two facts replace a backup setting you were previously trusting on faith.

One path needs a migration rather than a dashboard restore: a paused project past its restore window. Supabase currently keeps paused free-plan projects restorable in Studio for one year. After that window, download the last database backup and Storage objects, create a new hosted project, and follow Supabase’s documented migration steps. A local restore is a separate inspection path, not the only route back.

Download a backup and open it locally

You can pull a backup file down and open it on your own machine to inspect data or extract a handful of rows. Restore service after the hosted restore window by migrating into a new hosted project as described above. Supabase’s guide to restoring a downloaded backup locally gives the inspection procedure:

1. Download the backup from Database > Backups and read the Postgres version off the PG: prefix on the file.
2. Run supabase init in an empty directory.
3. Write that version into the CLI’s temp file: echo '15.6.1.115' > supabase/.temp/postgres-version, substituting your own version.
4. Start Postgres from the file: supabase db start --from-backup db_cluster.backup.
5. Verify with psql 'postgresql://postgres:postgres@localhost:54322/postgres' and check the tables you came for.

Two gotchas the docs publish and most write-ups skip. The earliest Supabase Postgres version that supports a local restore is 15.1.0.55; earlier versions can error out, which matters most for the old paused project you are trying to rescue. And a Postgres started by the Supabase CLI is not production ready and should not be used outside local development, so treat this as an inspection tool, not a hosting plan.

Listing and triggering backups from the Management API

Supabase’s Management API can list a project’s backups and trigger a PITR restore programmatically, authenticated with an access token against the project ref. The read half is the one worth wiring up first: a small scheduled check that asks whether last night’s backup exists and pages someone when it does not. That converts backup monitoring from a thing somebody remembers to open the dashboard for into a thing that tells you. Keep the write half behind a human, since a restore call changes the project.

Supabase point-in-time recovery, and the honest price of it

PITR replaces daily backups with continuous archiving and recovery at up-to-seconds granularity: choose a point before a bad write instead of only last night’s snapshot. Supabase archives Write Ahead Log files at two-minute intervals by default, and documents a worst-case recovery point objective (RPO) of two minutes. That is the number the cost argument turns on. A daily backup means a loss window of up to 24 hours; PITR means about two minutes.

Supabase’s current PITR usage and pricing documentation publishes both hourly and monthly rates: $0.137 an hour (about $100 a month) for 7 days of retention, $0.274 an hour (about $200) for 14 days, and $0.55 an hour (about $400) for 28 days. For a Pro organization with one project running on the required Small compute size, seven-day PITR is about $130 for a full month when that project receives the plan’s full $10 compute credit. It earns that cost for a narrow case: an app with a high write volume, where losing anything since last night’s backup would mean losing real orders, messages, or transactions.

The components matter because the $100 PITR line is not the complete project bill. Seven days of retention is about $100 a month, on top of the $25 Pro base. PITR also requires at least Small compute, listed at about $15 a month. Paid organizations receive $10 in monthly compute credits, but that credit is shared across the organization’s projects. With one Small project receiving the whole credit, the arithmetic is about $25 + $100 + $15 - $10 = $130; actual compute is billed hourly. Whether that is worth it comes down to what a lost day would actually cost you. If losing everything since last night means re-entering a handful of orders you can reconstruct from payment records and email receipts, a well-tested daily backup may cover the realistic loss window for a fraction of PITR’s price. If it means losing transactions no other system remembers, PITR is the stronger answer. Either way, the restore drill above is what tells you whether “well-tested” is true yet. PITR is a required project setting when using Supabase to handle protected health information under its HIPAA program, alongside a signed BAA and the HIPAA add-on; that is part of what the Supabase HIPAA add-on costs on the Team plan.

The same recovery work sits beside other data-loss patterns that show up across AI-built apps and the one-database, no-staging setup that turns a bad migration into the incident a backup was meant to undo. The backup you have not restored is a passed check sitting on top of an unrun test, and it is the cheapest claim on this list to verify.

Common questions about Supabase backups

What does a Supabase backup contain?

A Supabase backup on a paid plan holds the database: the schema, the table rows and the auth.users rows, kept for a rolling window of 7 days on Pro, 14 on Team and up to 30 on Enterprise, as checked on 16 August 2026. It does not hold Storage files (only their metadata), Edge Functions, Auth provider settings, API keys or project configuration, and deleting the project deletes every backup with it.

Does Supabase have built-in backups?

Yes, on paid plans. Supabase takes automatic daily database backups on Pro, Team, and Enterprise projects, and you find them under Database > Backups in the dashboard. The free plan has no platform-managed backup you can restore from, so free-plan projects need their own scheduled logical dumps. No plan’s built-in backup covers Storage files.

Does native backup cover Storage files?

No. On every plan, a Supabase database backup stores Storage metadata, not the object bytes. Restored metadata cannot recreate a deleted file. Files in buckets need their own copy, synced by a separate job through the S3-compatible Storage endpoint.

How long does Supabase keep database backups?

Pro keeps a rolling seven days of daily backups, Team keeps fourteen, and Enterprise can access up to thirty. The PITR add-on keeps the continuous window you pay for, starting at seven days. The free plan has no automatic backup available through the platform, so schedule and retain your own off-site copies.

Can I back up a Supabase project on the free plan?

Yes, by running schema, data, and role dumps on a schedule. With the Supabase CLI, a default dump alone is incomplete because it contains neither table data nor custom roles. Use the direct connection when IPv6 is available or Supavisor session mode on port 5432 from an IPv4-only runner. Store the encrypted artifacts outside Git and test them.

Can I schedule Supabase backups to GitHub or S3?

Yes, but you schedule it yourself. As of August 2026, Supabase’s backup documentation describes no built-in way to send a managed backup to a GitHub repository or an S3 bucket you control, and it recommends that free-plan projects export their own data with the CLI db dump command and keep off-site copies. The working shape is a runner you own: a GitHub Actions workflow on a nightly cron that runs the three supabase db dump commands above, encrypts the output, and pushes it to object storage with a lifecycle rule, plus a second job syncing Storage buckets through the S3-compatible endpoint on the same schedule. Keep the dump files out of the repository itself. A history rewrite cannot recall a dump already copied into a clone, fork, or cache.

How do I download a Supabase backup?

Download it from Database > Backups in the dashboard, then open it locally with the Supabase CLI: supabase init, write the version from the file’s PG: prefix into supabase/.temp/postgres-version, and run supabase db start --from-backup db_cluster.backup. Verify with psql on port 54322. The earliest Supabase Postgres version that restores locally is 15.1.0.55, and a CLI-started Postgres is for inspection only, not production.

Does a Supabase backup include Edge Functions, Auth settings, and API keys?

No. A database backup covers the database, which includes the auth.users rows but not the project configuration around them. Edge Functions, Auth provider settings and API keys, Realtime settings, read replicas, Storage object bytes, and project-level configuration are all outside the backup and have to be recreated or exported separately. That list is the main output of running a restore drill.

Do I need a third-party backup tool if I am on the Pro plan?

Only if Pro’s boundaries do not fit you. Pro’s daily backup covers the database for seven days and nothing else, so a paid tool earns its price when you need longer retention without PITR, when Storage buckets hold files you cannot regenerate, or when nobody wants to own a scheduled dump job. If you have not yet tested a restore, fix that before buying anything: a second untested backup adds cost, not safety.

Does deleting a Supabase project delete its backups?

Yes. Supabase says project deletion permanently removes all associated data, managed backups included. Create and verify a final logical database backup plus a copy of every bucket before deleting a project you might ever need to reconstruct.