PostgreSQL
Create a PostgreSQL restore schedule for SQL backups and validate the restored database with gates.
Loading documentation…
A PostgreSQL schedule imports a SQL backup into the exact PostgreSQL version you select, then evaluates the configured gates.
| Series | Exact version | Tier |
|---|---|---|
| 9.6 | 9.6.24 | Legacy |
| 12 | 12.22 | Legacy |
| 13 | 13.23 | Legacy |
| 14 | 14.24 | Supported |
| 15 | 15.19 | Supported |
| 16 | 16.15 | Supported |
| 17 | 17.11 | Supported |
| 18 | 18.6 | Supported |
These are the versions currently available in RestoreTrust. The console and the database-engine catalog are authoritative if the catalog changes. Prefer a Supported version for a new schedule unless your recovery target requires an exact Legacy version.
Use a plain SQL dump, optionally wrapped in one of the supported artifact layouts. pg_dump custom (-Fc), directory (-Fd), and native tar (-Ft) formats are not supported. Automatic detection does not convert them to SQL.
In the schedule's database step, select PostgreSQL and the exact version that matches the backup producer.
The dump format is SQL. Choose automatic detection or enforce the container and compression. Supported containers are none, tar, and ZIP; supported compression options are listed in Database restores.
If required, select a ZIP password or age secret metadata entry. The corresponding Kubernetes Secret must exist in the selected worker's job namespace.
Enter a target database name when the check must import into a specific name. If left empty, RestoreTrust uses restoretrust_restore.
Require a successful import, then add SQL probes whose first result value can be compared as a boolean, integer, or string. Add download, restore, or probe duration gates where they represent your recovery objective.
Useful probes test facts that should remain stable enough to be meaningful: a minimum row count in a critical table, the presence of a migration marker, or a known invariant. Keep queries read-only and avoid returning secrets or personal data.
The import runs under a temporary role without superuser privileges. Dumps requiring superuser-only constructs, such as event triggers or extensions outside the validator's allowlist, are rejected. Client meta-commands are restricted as well. Review the restore log if an otherwise valid SQL dump depends on privileges or extensions unavailable in the validation environment.
A SQL file can import without containing every table or record your service needs. Passing status proves only that PostgreSQL accepted the import. Add application-relevant probes and periodically review their thresholds.
Start a manual run, then review the restore log and probe results before enabling notifications or relying on recurring checks.