Supabase Physical vs Logical Backups: What Developers Need to Know in 2026

If you use Supabase, you may have noticed that database backups work differently from older tutorials you find online.

Some guides show a downloadable backup.gz file. Others tell you to run pg_dump or supabase db dump. Meanwhile, newer Supabase projects use physical backups by default.

So which backup type should you actually use?

The short answer is:

Physical backups are best for managed recovery inside Supabase, while logical backups are better when you need a portable database copy that you control.

For many production projects, the best strategy is not choosing one or the other. It is understanding what each backup protects you from and using both where appropriate.

As of 2026, Supabase projects running Postgres 15.8.1.079 or newer use the newer physical backup process by default. Older projects transition to physical backups after upgrading to an eligible Postgres version.

What Is a Logical Backup?

A logical backup exports the contents of a PostgreSQL database into a portable representation.

Instead of copying PostgreSQL’s underlying database files, a logical backup describes the database in a form that can later be used to recreate its structure and data.

Common PostgreSQL tools for logical backups include:

pg_dump

and, for Supabase projects:

supabase db dump

PostgreSQL logical backups are useful because they can be restored into another compatible database rather than being tied to the exact physical files of the original database server.

For a Supabase project, a logical backup is typically the better choice when you want:

• A backup file you can keep yourself
• An off-site database copy
• A database export for migration
• A backup that can be restored into another environment
• A copy for development or testing
• More control over long-term backup retention

Supabase specifically recommends that Free Plan users regularly export their data with the Supabase CLI db dump command and maintain off-site backups.

What Is a Physical Backup?

A physical backup works at a lower level.

Instead of representing your database as SQL statements or a logical dump, it captures the underlying files used by PostgreSQL to store the database.

Physical backups are particularly useful for restoring an entire PostgreSQL database efficiently and for supporting recovery systems such as Point-in-Time Recovery.

Supabase’s current backup infrastructure uses physical backups for newer projects. All projects running Postgres 15.8.1.079 or newer use the physical backup process by default.

The important difference for developers is that these physical backups are managed by Supabase.

You normally use them from:

Supabase Dashboard → Database → Backups

to restore your project.

You do not receive the underlying physical backup as a normal downloadable database file.

Supabase Physical vs Logical Backups at a Glance

Feature	Physical Backup	Logical Backup
Main purpose	Managed database recovery	Portable database copy
Used by newer Supabase projects	Yes	Created manually when needed
Downloadable directly	No	Yes
Good for migration	Limited	Yes
Useful for off-site storage	Not directly	Yes
Supports PITR workflow	Yes	No
Can be created with Supabase CLI	No	Yes
Can be stored in your own cloud storage	Not directly	Yes
Good for independent backup ownership	Limited	Yes

The distinction becomes especially important when you think about recovery versus portability.

Physical backups are optimized around restoring your hosted Supabase database.

Logical backups give you a database copy you can move and manage yourself.

Why Did Supabase Move to Physical Backups?

Physical backups fit naturally with Supabase’s managed recovery infrastructure.

They also make Point-in-Time Recovery possible when combined with PostgreSQL’s Write-Ahead Log, or WAL.

PostgreSQL records database changes in WAL files. During a PITR restore, Supabase first restores a physical backup and then replays the WAL records needed to reach the selected recovery point.

For example, imagine an incorrect query deletes customer records at:

3:17 PM

A normal daily backup may only let you return to yesterday’s database state.

With PITR, you may instead choose a recovery point shortly before the destructive query occurred, subject to the available recovery window. Supabase’s PITR system supports recovery with second-level selection granularity.

That makes physical backups highly useful for production recovery.

But it does not mean logical backups are obsolete.

They solve a different problem.

Why Logical Backups Still Matter

Suppose your production database is protected by Supabase’s native physical backups.

That is useful.

But now imagine you want to:

• Keep a database copy in another location
• Leave Supabase someday
• Restore the database locally
• Archive monthly database snapshots
• Move data into another PostgreSQL environment
• Keep backups longer than your Supabase retention period

A logical backup is much better suited to those jobs.

This is why a managed platform backup and an independent database backup should not automatically be considered the same thing.

Example

Your recovery setup could look like this:

Production Supabase Project
        │
        ├── Supabase Physical Backups
        │      └── Fast managed recovery
        │
        └── Logical Database Backups
               └── Independent off-site copies

The first protects your ability to recover within Supabase.

The second gives you portability and additional control.

How to Create a Logical Supabase Backup

Supabase provides a CLI workflow for creating logical backups.

For a migration or full manual backup workflow, Supabase currently documents separate exports for roles, schema, and database data.

Back up database roles

supabase db dump \
  --db-url "[CONNECTION_STRING]" \
  -f roles.sql \
  --role-only

Back up the schema

supabase db dump \
  --db-url "[CONNECTION_STRING]" \
  -f schema.sql

Back up the data

supabase db dump \
  --db-url "[CONNECTION_STRING]" \
  -f data.sql \
  --use-copy \
  --data-only \
  -x "storage.buckets_vectors" \
  -x "storage.vector_indexes"

You now have logical backup files that can be stored outside your Supabase project and used as part of a manual restore or migration workflow.

The Supabase CLI itself uses pg_dump while adding Supabase-specific behavior, including exclusions for managed schemas in its normal dump workflow.

If you need a detailed explanation of why an existing Supabase dashboard backup cannot be downloaded, see Why Can’t I Download My Supabase Backup? Physical Backups Explained and link it to your published article URL.

What Happens When PITR Is Enabled?

Point-in-Time Recovery relies on physical backups rather than downloadable logical backups.

When PITR or physical backups are enabled, Supabase no longer generates the older downloadable logical backup.gz file. This is expected behavior, not a missing backup or dashboard error.

Even if you later disable PITR, new backups continue to use the physical backup system.

If you want a portable backup afterward, Supabase recommends creating a logical backup using:

supabase db dump

or:

pg_dump

This is one of the biggest reasons developers should understand the difference between the two backup types.

Turning off PITR does not turn physical backups back into downloadable logical backups.

Which Backup Should You Use?

The right choice depends on what you are trying to accomplish.

I want to recover my hosted Supabase project

Use Supabase’s physical backups.

Paid Supabase projects receive automatic daily backups, with the available retention period depending on the plan. These backups can be restored from the Database → Backups section of the dashboard.

I want to recover to a specific point in time

Use PITR.

This is particularly useful for production databases where losing a full day of changes would be unacceptable. PITR combines physical backups and WAL information to restore the database to a selected recovery point.

I want a database file I control

Create a logical backup.

Use:

supabase db dump

This gives you a portable backup that you can store somewhere outside Supabase.

I want to migrate to another database

A logical backup will usually be the more useful format because logical exports are designed to recreate database objects and data in another PostgreSQL environment.

I want an additional off-site backup

Create logical backups and store them separately from your production platform.

For example, you could keep backups in secured object storage, another server, or your own Google Drive account.

If you do not want to manually create and upload database backups each time, SupaBackup can automate Supabase database backups and save them to your Google Drive.

Physical Backup vs Logical Backup: Which Is Safer?

Neither backup type is automatically “safer.”

They protect against different risks.

Consider two situations.

Situation 1: Accidental production data deletion

You accidentally update or delete thousands of records.

A recent physical backup or PITR recovery point may be your fastest recovery option.

Situation 2: You need your data outside Supabase

You need to migrate, inspect an independent copy, or keep backups outside the platform.

A logical backup is much more useful.

So instead of asking:

Which backup type is better?

A better question is:

What failure am I trying to recover from?

For an important production application, relying on only one recovery path may give you fewer options when something goes wrong.

Do Physical or Logical Backups Include Supabase Storage Files?

This is an important limitation that applies when planning your overall backup strategy.

Supabase database backups do not include the actual objects stored through the Storage API.

The database contains metadata about those objects, but the files themselves are stored separately. Restoring an older database backup therefore will not recreate Storage objects that were deleted after that backup.

For example, if your application stores:

• User avatars
• PDFs
• Invoices
• Product images
• Videos
• Uploaded documents

a database backup alone is not necessarily a complete application backup.

You should plan database recovery and Storage recovery separately.

Can a Physical Backup Be Restored to a New Supabase Project?

Supabase also provides a Restore to a New Project feature for eligible paid projects using physical backups.

The process creates a database copy in a new project and can transfer database schema, data, indexes, roles, permissions, Auth user records, and the encryption root key. However, components such as Storage objects, Edge Functions, Auth settings, API keys, Realtime settings, and some project configuration still require separate handling.

This is useful for scenarios such as:

• Testing with production-like data
• Creating a recovery project
• Investigating database problems
• Duplicating database state without overwriting production

But this feature is still different from owning a downloadable logical backup.

A Practical Backup Strategy for Supabase Developers

For a production Supabase application, a simple layered strategy might look like this:

Layer 1: Supabase native backups

Use Supabase’s managed backups as your primary platform-level recovery option.

Layer 2: PITR when your recovery requirements justify it

If your database changes frequently and losing several hours of data would be costly, evaluate Point-in-Time Recovery.

Layer 3: Independent logical backups

Create logical backups so you have portable copies of your database outside the managed physical backup system.

Layer 4: Off-site storage

Do not leave your only independent backup on your development computer.

Keep it somewhere controlled and separate from production.

If you want to avoid remembering to export the database manually, you can automate your Supabase database backups and keep those backups in your own Google Drive.

Layer 5: Test recovery

Creating backup files is not enough.

You should know whether they can actually be restored.

Before an emergency happens, test important backups in a safe environment such as local development, staging, or a separate project.

For a practical recovery workflow, see How to Restore a Supabase Database Backup Safely.

Physical vs Logical Supabase Backups: The Bottom Line

Supabase physical and logical backups are not competing versions of the same feature.

They serve different purposes.

Physical backups are ideal for Supabase-managed recovery and are part of the infrastructure behind features such as daily restores and PITR.

Logical backups are portable exports that give developers more control over where database copies are stored and how they are used.

In 2026, newer Supabase projects use physical backups by default, which is why older tutorials showing downloadable dashboard backup files may no longer match what you see in your project.

For many production applications, the strongest approach is therefore:

Use Supabase’s managed recovery options and maintain an independent logical backup when you need portability or off-site retention.

That way, if something goes wrong, you are not limited to a single recovery path.