1. Guides
  2. Run restore tests
  3. Restore types
  4. Databases
  5. PostgreSQL
Website
  • Overview
  • Quickstart
  • How RestoreTrust works
  • Requirements
  • Organizations and projects
  • Project workers
  • Test schedules
    • File checks
  • Validation gates
  • Time zones and dates
  • Manual runs
  • Notifications
  • Check results
  • Execution logs
  • Reports
  • Evidence and verification
  • Team and roles
  • API keys
  • Billing and plans

PostgreSQL

Create a PostgreSQL restore schedule for SQL backups and validate the restored database with gates.

Loading documentation…

Database restores< PreviousMySQLNext >

Powered by heyo

On this page

Available versionsConfigure the restore

A PostgreSQL schedule imports a SQL backup into the exact PostgreSQL version you select, then evaluates the configured gates.

Available versions

SeriesExact versionTier
9.69.6.24Legacy
1212.22Legacy
1313.23Legacy
1414.24Supported
1515.19Supported
1616.15Supported
1717.11Supported
1818.6Supported
Use the current catalog

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.

Configure the restore

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.

  1. 1

    Select PostgreSQL and a version

    In the schedule's database step, select PostgreSQL and the exact version that matches the backup producer.

  2. 2

    Describe the backup layers

    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.

  3. 3

    Add decryption settings

    If required, select a ZIP password or age secret metadata entry. The corresponding Kubernetes Secret must exist in the selected worker's job namespace.

  4. 4

    Choose the target database

    Enter a target database name when the check must import into a specific name. If left empty, RestoreTrust uses restoretrust_restore.

  5. 5

    Define success

    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.

Import success alone is weak evidence

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.