How to back up Supabase automatically.

Why Supabase backups matter

Supabase is where a lot of teams keep their entire product database: users, tenants, billing state, content. Because you write SQL and manage RLS yourself, a small mistake in a migration or an over-permissive policy can quietly change or delete rows across every tenant at once.

A concrete scenario: a migration adjusts an RLS policy so authenticated users can update their own row, but the USING clause omits the tenant check. Within a day, one tenant's user updates leak into another tenant's records. You need to restore the affected rows without rolling back yesterday's other work. A row-level restore from a point-in-time snapshot does this; a full-project PITR does not.

• Migrations that drop columns or tables and cascade to referenced rows.
• Broken RLS policies exposing or overwriting rows across tenants.
• Manual UPDATE or DELETE in the SQL editor without a WHERE clause.
• Buggy edge functions performing bulk writes with the service role key.
• GDPR right to erasure needing evidence of what a record looked like on a specific date.

What Supabase gives you natively

Supabase paid plans include daily backups and, on Pro and above, PITR up to seven days. Both are full-project restores.

Understand exactly what is and is not covered before you decide you do not need external backups:

• Daily backups. Retained for 7 days on Pro, 14 days on Team, 30 days on Enterprise. Restore is a full-project rollback.
• Point-in-time recovery. Up to 7 days on Pro, longer on higher tiers. Also a full-project restore, not a per-row or per-table one.
• pg_dump. You can run pg_dump yourself against the connection string. You still need to build storage, retention and restore around it.

None of Supabase's built-in options let you restore a single row or table back into the live project without also rolling back everything else that happened since.

Backup methods compared

For any Supabase project with real users, an automated backup with row-level restore is the only method that recovers from a mistake without also throwing away everything good that happened in the meantime.

Set up automated Supabase backups

Connecting Supabase to Backup247 takes about ten minutes. It uses a read-only Postgres role you create yourself; no service role key is ever needed.

1. Create your Backup247 account

   Start the 14-day trial from the sign up page. No card required.

2. Create a read-only role

   Run the SQL snippet provided in the connector setup to create a role with SELECT on the schemas you want to back up.

3. Connect the project

   Paste your Supabase project URL and the read-only role credentials into the Supabase connector.

4. Scope the connector

   Pick which schemas and tables are in scope. RLS policies, indexes, functions and triggers are captured automatically for those schemas.

5. Pick a schedule

   Daily is the default. Increase to hourly for busy tables such as orders, sessions or events.

6. Verify the first snapshot

   Once the first run completes, browse the snapshot to confirm tables, row counts and schema objects are captured before you rely on it.

See the connector details on the Supabase integration page, or compare plans on pricing.

How restore works

The point of a backup is the restore. Backup247 gives you three restore paths for Supabase, all from the same snapshot browser:

• Single row. Preview the diff between the snapshot and the live row, then restore just that row. Foreign keys are respected.
• Whole table. Restore every row in a table to a chosen point in time. Existing rows are diffed so you can accept or reject each change.
• Schema. Replay policies, indexes, functions and triggers exactly as they were on any past day, useful when a migration goes wrong.

Supabase backup checklist

• Daily automated snapshot of every schema that holds business data.
• Hourly snapshots for high-write tables such as orders or sessions.
• Retention of at least 90 days, longer if you have compliance obligations.
• Backup storage in the EU with encryption at rest and a DPA on file.
• Alerts when a scheduled backup fails or when row counts drop unexpectedly.
• A restore drill every quarter: pick a random row, restore it, confirm it matches.
• The backup role is read-only and its password is rotated at least once a year.

Frequently asked questions