How backups work
DBHost uses pg_dump piped through gzip to create compressed SQL backups. You can trigger a backup manually. Active standard databases receive a daily automatic backup with 30-day retention in production. A preview created through Preview CI has no daily logical backup by default; you can choose daily backup when creating it or change that choice while it is active.
Automatic jobs run asynchronously throughout the UTC day. The scheduler checks for work each minute, prioritizes databases by their last verified backup, and catches up after interruptions. The dashboard shows completion after the backup artifact has been verified; the scheduling tick itself is not proof that a backup completed. There is no single guaranteed backup time.
In production, durable backups are stored off-host in AWS S3 eu-north-1 and exposed in the dashboard as timestamped .sql.gz files.
Triggering a backup
- Go to your database detail page
- Click Export Data to start a new backup and jump to the backups page
- Or click Backups and use Trigger Backup from there
The backup is queued as an operation. The dashboard polls its status and updates
the list without requiring a page refresh.
Viewing backup history
The backups page shows all available backups with:
- Filename (timestamp-based:
YYYYMMDD_HHMMSS.sql.gz)
- Size (compressed)
- Created at (UTC)
- Actions — role-appropriate download, delete, and limited-rollout actions
Developers can view and download backups. Owners and admins can trigger and
delete backups. Restore and import controls are hidden unless the exact
database is enrolled in the limited rollout described below.
Restoring from a backup (limited rollout)
The staged restore design uses an isolated staging database, validates the
artifact, creates and verifies a pre-restore backup, then performs a guarded
swap during a maintenance window of at most five minutes. The previous database
is retained in isolation for 24 hours for an operator-controlled rollback.
An enabled release flag is not target authorization. Restore remains available
only when the database ID/name, managed-registry generation, operation ID and
agent capability all match the approved rollout policy.
Importing a database dump (limited rollout)
The staged import flow accepts a pg_dump file from another host or platform.
It is not a generally available customer migration path; the controls appear
only for an exact enrolled database.
- Initialize an upload operation.
- Select a file (
.sql, .sql.gz, .dump, or .backup - max 512 MB).
- Upload directly to the isolated S3 staging prefix with the short-lived
presigned URL.
- Complete the upload so DBHost can validate size, checksum, format and schema
inventory before a restore can proceed.
Restore staging has a 30-minute execution limit. Plain .sql and .sql.gz
files must also remain within 512 MB after decompression, and each physical SQL
line - including one COPY row - must be no larger than 16 MiB. Use a custom
.dump or .backup file when a single value needs a larger line.
The file does not travel through Vercel or Caddy. Upload completion does not by
itself authorize a production restore.
After a successful staged restore, DBHost verifies that restored objects belong
to the limited tenant owner before the database can become active.
Retention
Ordinary logical backups of standard databases, and of previews with daily backup selected, follow 30-day retention in production. Automated cleanup runs as part of the scheduled backup job.
A deletion backup is a separate lifecycle artifact. It is bound to the exact
delete operation, remains downloadable only during that database’s seven-day
recovery window, and is permanently removed together with the physical
tombstone. It does not become an ordinary 30-day backup after deletion.
Disabling daily logical backups for a preview does not exclude it from
infrastructure VM backups or manually retained snapshots. Those disk copies
may still contain preview data after its lease or seven-day recovery window;
they are not controlled by the preview backup choice or the logical-backup
retention job. Manual snapshots are reviewed weekly and kept for at most 30
days from creation unless an incident or rollback has a documented, time-limited
exception.
Downloading and deleting backups
- Use Download to fetch the exact
.sql.gz file for local storage or
operator restore work. S3 returns the object through a 15-minute presigned
URL when the direct-download capability is available; the backup
body does not pass through Vercel. Local storage uses bounded streaming with
an idle timeout.
- Use Delete to remove a backup file permanently from backup storage.
Deleting a backup cannot be undone.
