Backups_
Scheduled backups, manual backups, restores, and point-in-time recovery for your PostgreSQL database.
3 min read
Native databases are backed up automatically. Backups are stored off the database instance and restorable from the API. For finer recovery granularity than scheduled backups, enable point-in-time recovery.
Automatic backups
Every database gets a default backup policy when it is provisioned, so you have scheduled backups from day one. You can adjust the default policy, or add more policies with different schedules and retention windows.
Backup policies
A policy defines a schedule and a retention period in days. In the Console, open your database's Backups page and click Create policy, then pick the schedule and retention. Programmatically, create one with:
| Parameter | Value | Description |
|---|---|---|
policyId | custom ID or unique() | Policy identifier |
name | text | Display name |
schedule | cron expression | When backups run, for example 0 3 * * * |
retention | 1 - 365 days | How long backups from this policy are kept |
List, update, and delete policies with listBackupPolicies, updateBackupPolicy, and deleteBackupPolicy. The number of policies you can create depends on your plan.
Manual backups
Take an on-demand backup before a risky change. In the Console, click Manual backup on the Backups page. Programmatically:
The backup runs asynchronously with status pending until it completes. List backups and check their status with listBackups, or fetch one with getBackup.
Restore from a backup
Restoring replaces the database's current data with the backup's contents. The database status moves to restoring and returns to ready when the restore completes; connections are unavailable during the restore.
Track progress with getRestoration or the database status.
Everything written after the backup was taken is lost when you restore it. If you need the current state too, take a manual backup first, or use a branch to inspect data without touching the live database.
Point-in-time recovery
Scheduled backups recover to fixed snapshots. Point-in-time recovery (PITR) continuously archives the write-ahead log, so you can restore to any moment inside the retention window, for example the second before a bad migration ran.
Enable PITR when creating the database, from Settings > PITR in the Console, or through the API:
pitrRetentionDays accepts 1 to 35 days. PITR is billed as an add-on on top of your specification; see pricing.
Check the recovery window
You can retrieve the time ranges you can restore to. Right after enabling PITR, no recovery window is available yet; the window opens once continuous archiving has captured its first segment.
Restore to a point in time
Pass a Unix timestamp inside the recovery window:
Like a backup restore, a PITR restore is in-place: the database is unavailable while restoring and everything after the target time is discarded.
Limits
| Limit | Value |
|---|---|
| Backup retention | 1 - 365 days |
| PITR retention | 1 - 35 days |
| Backup policies | Plan-dependent |
Was this page helpful?
Share what worked or what we should fix. Once approved, our agents automatically apply suggested updates to the docs.