How to Back Up a Supabase Project: Methods, Options, and What to Consider

Losing a production database without a backup is one of the more painful experiences in web development. If you're building on Supabase, understanding how its backup system works — and where the gaps are — is worth doing before you need it, not after.

What Supabase Actually Stores (And What That Means for Backups)

A Supabase project isn't just a database. It includes:

• PostgreSQL database — your tables, rows, relationships, and data
• Storage buckets — uploaded files and assets
• Auth configuration — user records, providers, JWT settings
• Edge Functions — serverless function code
• Project settings and API keys — environment-specific configuration

Most backup strategies focus on the PostgreSQL database because that's where your application data lives. But a complete recovery scenario may require restoring more than just rows — so it's worth knowing which parts of your project are covered by which method.

Built-In Backup Options on Supabase

Point-in-Time Recovery (PITR)

Point-in-Time Recovery is Supabase's most robust backup mechanism. It continuously archives your database's write-ahead log (WAL), which records every change made to the database. This means you can restore your database to any specific moment — not just a daily snapshot.

PITR is available on Pro plans and above. The retention window (how far back you can restore) varies by plan tier. On the Pro plan, Supabase offers a default retention period; higher tiers extend this further.

This is the gold standard for production databases where data integrity and minimal data loss matter. If something goes wrong at 2:47 PM on a Tuesday, you can restore to 2:46 PM — not just to "yesterday morning."

Daily Backups (Scheduled Snapshots)

On the Pro plan, Supabase also runs automated daily backups. These are full database snapshots taken once per day and retained for a set period. You can download these backups directly from the Supabase dashboard under Project Settings → Backups.

The trade-off with daily snapshots is the recovery point objective (RPO). If your database is backed up at midnight and something goes wrong at 11 PM the next day, you're potentially losing nearly 24 hours of data. For low-traffic or non-critical projects, this may be acceptable. For high-transaction production environments, it usually isn't.

Free plan projects do not include automated backups. This is a commonly misunderstood limitation.

Manual Backup Methods

Regardless of your plan, you can manually back up your Supabase PostgreSQL database using standard PostgreSQL tools.

Using pg_dump

pg_dump is the standard PostgreSQL utility for exporting a database. Supabase exposes a direct PostgreSQL connection string, which you can find in Project Settings → Database → Connection string.

A basic export looks like this:

pg_dump "postgresql://postgres:[PASSWORD]@[HOST]:5432/postgres" --format=custom --file=supabase_backup.dump 

Using --format=custom produces a compressed, flexible dump that can be restored with pg_restore. You can also use --format=plain for a human-readable SQL file.

This approach gives you full control over timing, frequency, and storage destination. You can automate it with a cron job, a CI/CD pipeline, or a cloud function that runs on a schedule and uploads the dump to S3, Google Cloud Storage, or another location.

Using the Supabase CLI

The Supabase CLI offers a db dump command that wraps pg_dump with some project-aware defaults:

supabase db dump --db-url "your_connection_string" -f backup.sql 

This is useful if you're already using the CLI as part of your development workflow. It outputs a plain SQL file suitable for reimporting.

Backing Up Storage Buckets

Your Supabase Storage files are not included in database backups. If your application relies on user-uploaded images, documents, or assets stored in Supabase Storage, those need a separate strategy — typically syncing bucket contents to an external storage service using the Supabase Storage API or rclone.

🔁 Restoring From a Backup

Restoration depends on the method used:

• PITR: Initiated through the Supabase dashboard. You select a target timestamp and Supabase handles the recovery process.
• Daily snapshots: Also managed through the dashboard. Select a backup date and restore.
• pg_dump files: Use pg_restore (for custom format) or psql (for plain SQL) against your database connection string.

Test your restoration process before you need it. A backup you've never restored from is a backup you don't fully trust.

Variables That Shape the Right Approach for Your Project 🛠️

Several factors determine which combination of methods makes sense:

• Plan tier — Free plan users have no automated backups and rely entirely on manual methods
• Acceptable data loss window — How much data can you afford to lose? An hour? A day? Near-zero?
• Database activity level — High-transaction databases benefit more from PITR than from daily snapshots
• Compliance or data retention requirements — Some industries require specific backup frequencies and retention periods
• Storage contents — If your app stores files, database-only backups leave a gap
• Technical comfort — Automating pg_dump requires scripting or pipeline knowledge; dashboard-based backups require none
• Budget — PITR and higher retention windows are tied to paid plan tiers

A personal project with low traffic and non-critical data sits in a completely different position than a production SaaS with active users and financial records. The same tools are available to both — but the acceptable risk profile, and therefore the right configuration, differs significantly between them.