How to Back Up a Supabase Project

Backing up a Supabase project is not optional—it is a critical responsibility for any team relying on PostgreSQL databases in production. Whether you are managing a growing SaaS product, handling user-generated content, or running internal tools, a properly designed backup strategy protects you from accidental deletions, migration failures, corrupted data, or even regional outages. Supabase provides powerful tools built on PostgreSQL, but structured planning and disciplined processes are necessary to ensure reliable recovery.

TLDR: Backing up a Supabase project primarily means backing up your PostgreSQL database, storage files, and configuration. You can rely on Supabase’s automated backups on paid plans or create manual backups using pg_dump. A complete strategy combines automated snapshots, periodic manual exports, and verified restoration tests. Always store backups securely and test recovery procedures before you need them in production.

In this guide, we will break down how to properly back up a Supabase project, covering automated backups, manual database exports, storage object backups, and best practices for long-term data protection.

Understanding What Needs to Be Backed Up

A Supabase project consists of several important components. Backing up only one of them may leave you exposed.

You should consider securing:

• PostgreSQL database (tables, schemas, indexes, functions, triggers)
• Auth data (users, roles, policies)
• Storage buckets (uploaded files and media)
• Edge functions and configuration
• Environment variables and secrets

The PostgreSQL database is usually the most critical asset. Supabase uses standard Postgres under the hood, which makes it compatible with mature database backup tools.

Automatic Backups in Supabase

If you are on a paid Supabase plan, the platform provides automated daily backups. These backups offer point-in-time recovery (PITR), which allows you to restore your database to a specific moment in time.

How Automatic Backups Work

Supabase uses PostgreSQL’s write-ahead logging (WAL) to support:

• Daily snapshot backups
• Continuous WAL archiving
• Point-in-time restore capability

This system reduces the risk of data loss in scenarios such as:

• Accidental table deletion
• Faulty migrations
• Application-level bugs
• Data corruption

How to Restore from an Automatic Backup

1. Go to your Supabase Dashboard.
2. Open the project.
3. Navigate to Database → Backups.
4. Select a snapshot or point-in-time recovery option.
5. Confirm restore operation.

Important: Restoring a backup will overwrite your current database state. Always verify timing and consider exporting the current state before restoration.

Manual Database Backups Using pg_dump

Even if automatic backups are enabled, experienced teams implement independent manual backups. This ensures redundancy and gives you portable database dumps that can be restored outside Supabase if necessary.

The recommended method is pg_dump, a PostgreSQL-native tool.

Step 1: Retrieve Your Database Credentials

From the Supabase Dashboard:

• Open Project Settings
• Go to Database
• Copy the connection string (URI)

You will need:

• Host
• Port
• Database name
• User
• Password

Step 2: Run pg_dump

Using the terminal:

pg_dump "postgresql://USER:PASSWORD@HOST:PORT/DATABASE" -F c -f backup.dump

Options explained:

• -F c: Custom compressed format
• -f: Output file

The custom format is strongly recommended because it allows flexible restoration options.

Step 3: Secure the Backup

Once created:

• Store the file in encrypted cloud storage (e.g., S3, Google Cloud Storage)
• Enable server-side encryption
• Restrict access permissions
• Rotate backup storage credentials periodically

Restoring a Manual Backup

To restore a backup created with pg_dump, use pg_restore:

pg_restore -d "postgresql://USER:PASSWORD@HOST:PORT/DATABASE" backup.dump

You may also restore into:

• A new Supabase project
• A local PostgreSQL container
• A staging database

Restoring into staging first is considered best practice. It allows verification before touching production data.

Backing Up Supabase Storage

Supabase Storage handles user-uploaded files such as images, documents, and videos. These files are not included in pg_dump backups and must be managed separately.

Options for Storage Backup

• Use Supabase Storage API to download all objects
• Mirror storage buckets to external object storage
• Create scheduled export scripts

For automated backups, you can:

1. List objects in each bucket.
2. Download them programmatically.
3. Upload to a secondary storage provider.

Ensure metadata such as file paths and permissions are also preserved.

Backing Up Auth and Policies

Supabase Auth stores user data inside the PostgreSQL database. Therefore, database backups include:

• User accounts
• Roles
• Row Level Security (RLS) policies

However, you should still document:

• Custom JWT settings
• OAuth provider configurations
• SMTP credentials

Store this configuration information securely in version-controlled documentation or encrypted secret management tools.

Backing Up Edge Functions

Edge Functions are not stored inside your database. They should be backed up through:

• Version control systems (Git)
• CI/CD pipelines
• Offsite repository hosting

Every deployment pipeline should:

• Pull from a repository
• Include version tags
• Support rapid redeployment

If your Edge Functions live only inside a local environment without version control, you are operating at significant risk.

Creating a Backup Policy

Strong backup strategies are structured around policy, not convenience.

Consider defining:

• Backup frequency: Daily automatic + weekly manual exports
• Retention period: 7–30 days for snapshots, longer for archives
• Storage location: Separate geographic region
• Access controls: Least privilege principle
• Testing schedule: Quarterly restore validation

A documented policy ensures backups are not forgotten during rapid development cycles.

Testing Your Backups

A backup is useless if it cannot be restored. Testing recovery is essential.

A proper recovery test involves:

1. Restoring backup into staging.
2. Verifying table counts and sample data.
3. Checking RLS policies and authentication.
4. Confirming application connectivity.

This process should be scheduled regularly. Many organizations perform quarterly disaster recovery drills.

Common Mistakes to Avoid

• Relying only on automatic backups without independent exports
• Failing to test restoration
• Storing backups unencrypted
• Keeping backups in the same region as production
• Ignoring storage bucket exports

Each of these mistakes can result in avoidable data loss.

Recommended Backup Strategy for Production Projects

For serious production environments, a dependable approach looks like this:

• Supabase automatic daily backups enabled
• Weekly manual pg_dump stored externally
• Nightly storage bucket mirroring
• Version-controlled Edge Functions
• Quarterly restoration testing

This layered approach creates redundancy and eliminates single points of failure.

Conclusion

Backing up a Supabase project is fundamentally about safeguarding your PostgreSQL database while also securing stored files, authentication data, and serverless functions. Supabase simplifies much of the process through built-in automated backups, but responsible operators supplement these with independent exports and verified recovery procedures.

A well-designed backup strategy is not reactive—it is proactive. It anticipates mistakes, outages, and unexpected incidents before they happen. By combining automated recovery, manual redundancy, secure offsite storage, and disciplined testing, you can ensure that your Supabase project remains resilient, recoverable, and professionally managed.

Data loss is rarely caused by a lack of tools. More often, it results from a lack of planning. Take the time to implement a clear, documented backup process today—before you need it tomorrow.