Does Render back up my database automatically, or do I need to set it up?

Render continuously backs up every paid Postgres instance for point-in-time recovery, so there's nothing to schedule or enable. Databases on the Free instance type are not backed up. Upgrade to a paid instance type to get both PITR and logical exports.

Should I use point-in-time recovery or a logical export to recover lost data?

For most data-loss scenarios, use point-in-time recovery. Because Render archives changes continuously, PITR almost always recovers more recent data than your latest logical export, and it spins up an isolated instance you can validate before switching over. Reach for a logical export when you need a portable copy: moving data to another platform, seeding a development environment, or keeping a long-term archive outside Render.

Will restoring overwrite my existing database?

Point-in-time recovery doesn't overwrite the original database. When you trigger PITR, Render spins up a new database instance that reflects the original instance's state at the time you choose, and you repoint your services only after validating it. Restoring a logical export is different: the pg_restore and psql commands here drop existing objects, so only restore into an empty database.

Can I restore a Render export to a PostgreSQL database that isn't on Render?

Yes. A logical export (or a pgdump file) is standard PostgreSQL output, so you can restore it into any PostgreSQL instance, whether on Render, on another platform, or on your local machine, using pgrestore or psql. Match your client's major version to the target database to avoid compatibility errors.

Is point-in-time recovery included in my plan, or does it cost extra?

PITR is included with every paid Render Postgres instance, with no separate backup add-on to turn on. Your plan sets the length of the recovery window: 3 days on Hobby and 7 days on Pro or higher. Logical exports are also included and retained for seven days after creation, regardless of plan.

Do I still need my own backups if Render already provides PITR?

For most teams, PITR covers day-to-day recovery. Keeping your own logical exports offsite still matters if you want protection independent of any single provider, retention longer than your recovery window, or a copy you can restore elsewhere. That's the reasoning behind the 3-2-1 rule: automate a copy to external storage such as S3 for the offsite leg.

Databases

How to back up and restore PostgreSQL databases

November 19, 2025

Database loss happens. A mistyped DELETE query, application bugs, security breaches, or infrastructure failures can eliminate critical information. This guide explores Render's backup architecture, shows you how to perform manual backups, covers restoration workflows, and examines strategic considerations for disaster recovery planning.

Render's managed PostgreSQL service implements continuous point-in-time recovery (PITR) for paid instances. This enables you to restore your database to any previous state from the past few days, so you can recover from an accidental table drop or other data loss. For a conceptual look at how PITR works, including the write-ahead log it relies on, see Postgres features that matter for production.

Your database's available recovery window depends on your workspace plan:

Hobby: Past 3 days
Pro or higher: Past 7 days

One restriction applies to how recent your restore target can be: you can't restore to a time within ten minutes of the current time.

Render does not provide recovery capabilities for the Free Render Postgres instance type. To enable these capabilities, you need to upgrade to a paid instance type.

Upgrading from Hobby to a higher plan does not retroactively backfill your recovery window. Instead, your existing 3-day window extends to 7 days going forward.

Manual backups give you control over timing, format, and storage location. Create one before a major schema migration, before a deploy that changes data structures, when you need a development copy, or to keep an external backup archive.

Render enables you to create and export logical backups from the Render Dashboard. These are retained for seven days after creation, regardless of your workspace plan. You can trigger these backups from your database's Recovery page by clicking Create export.

You can also use PostgreSQL's pg_dump utility for manual backups. pg_dump offers multiple formats. Plain SQL generates human-readable statements but is inefficient for large databases. Custom format (-Fc) produces compressed binary output and supports faster, parallel restoration, although the dump itself still runs as a single process. Only the directory format (-Fd) supports parallelizing the dump step as well.

bash

# Set connection string from Render Dashboard
DATABASE_URL="postgresql://user:password@host.render.com/dbname"

# Create backup in custom format
pg_dump -Fc $DATABASE_URL > backup_$(date +%Y%m%d_%H%M%S).dump

# -Fc creates compressed custom format
# Production: add error handling, verify integrity, automate secure storage

You can verify backup integrity to ensure restorability:

bash

# List backup contents without restoring
pg_restore --list backup_20240115_143022.dump

Render offers PITR for all paid database instances. Navigate to the Recovery page on your PostgreSQL service dashboard, scroll down to the Point-in-Time Recovery section, and click Restore Database to begin the restoration process.

When you trigger PITR, Render spins up a new database instance that reflects your original instance's state at a specified time in the past. This provides safety through isolation, so you can validate restored data before switching application connections.

From there, fill out the form by providing the following information:

Provide a name for the new database instance
Specify an available date and time to restore to (you can't restore to a time within ten minutes of the current time)
Select whether to copy existing settings (the recovery instance always copies the original instance's IP address allow list, regardless of this choice)
Start the recovery

Once the status of the recovery instance advances to Available, validate data completeness in the new instance. Update any application environment variables to point to the new instance, and delete or suspend the original instance if appropriate.

Manual restoration gives you flexibility for migrating between platforms, seeding development environments, or recovering from external archives.

Important warnings before you proceed:

The commands below include flags to drop relevant databases and then recreate them
Do not restore into a database that contains important data in the same schema as the export
In the event of data loss, Render recommends using point-in-time recovery instead, since PITR almost always enables you to recover more recent data than what's available in your latest export

For logical backups exported from Render:

Go to your database's Recovery page and click the .dir.tar.gz download link for any available export
Obtain the external database URL for your target database (if restoring to a Render-hosted database)
Extract the archive, then restore the directory-format export with pg_restore

bash

# Render exports are directory-format archives, so extract first
tar -zxvf 2025-02-03T19_21Z.dir.tar.gz

# Restore the extracted directory to your target database (drops existing objects)
pg_restore --dbname=$DATABASE_URL --verbose --clean --if-exists \
  --no-owner --no-privileges --format=directory \
  2025-02-03T19:21Z/my_render_database_name

# --format=directory matches Render's export format
# --clean drops existing objects before restoration; --no-owner skips ownership

Alternative approaches for different scenarios:

bash

# Restore plain SQL backup
psql $DATABASE_URL < backup_20240115_143022.sql

# Restore only specific tables
pg_restore -t users -t orders -d $DATABASE_URL backup.dump

PostgreSQL version compatibility affects success. Your pg_dump version should match or exceed the major version of the source database you're backing up, and your pg_restore version should match the major version of the database you're restoring into. You can verify compatibility:

bash

# Check local client version
pg_dump --version

# Check Render database version
psql $DATABASE_URL -c "SELECT version();"

Common failure modes include network timeouts, authentication failures, insufficient disk space, or connection pool exhaustion. Long-running pg_dump processes hold connections for extended periods, potentially causing "too many connections" errors.

Common error resolutions:

"too many open files": ulimit -n 4096
"connection timeout": Verify the external database URL and confirm your client's IP is in the database's allow list
"permission denied": Use --no-owner --no-privileges

Basic error handling pattern:

bash

if pg_dump -Fc $DATABASE_URL > backup.dump; then
  echo "Backup completed successfully"
else
  echo "Backup failed with exit code $?"
fi

Effective strategy balances Recovery Point Objective (RPO, the maximum acceptable data loss) with Recovery Time Objective (RTO, the maximum acceptable downtime). Financial applications might require 5-minute RPO and 30-minute RTO, while content systems might accept 24-hour RPO and 4-hour RTO.

The 3-2-1 backup rule: three total copies, two different storage types, one offsite. For Render: primary database, Render's point-in-time recovery backups, manual logical backups exported to external storage like S3. Render's guide on backing up Postgres to Amazon S3 walks through automating that last copy with a cron job.

Test your recovery process regularly to validate backup integrity, at least quarterly for production systems. A basic test involves restoring a recent backup to a new instance, verifying the data is complete, running your application's tests against it, and recording how long the restore took along with any issues you hit.

Establish documented backup policies specifying frequency, retention, and responsibilities. Configure monitoring for backup failures. All paid Render Postgres databases include point-in-time recovery: Hobby plans provide 3 days of recovery window, while Pro or higher plans provide 7 days. Review Render's PostgreSQL documentation for plan-specific features and detailed backup information.

How to back up and restore PostgreSQL databases

How does Render's automated backup system work?

How do I create a manual database backup?

How do I restore from point-in-time recovery?

How do I restore from a manual backup file?

Which pg_dump and pg_restore versions do I need?

How do I handle backup errors and connection issues?

How should I plan my backup strategy?

How do I test my recovery process?

What should I do next?

Frequently asked questions