PostgreSQL Backup & Restore

How automated backups, restore-from-backup, and point-in-time recovery work for managed PostgreSQL services.

Every managed PostgreSQL service can be configured to take continuous backups — a daily base backup plus a continuous stream of write-ahead log (WAL) segments — to an S3-compatible bucket you control. Once those are in place, you can spin up a brand-new database from any captured point in time without touching the source database.

This page covers what we back up, how to read the Backups tab, and how to restore in the two supported modes.

What we back up

When you turn backups on for a Postgres service, Simplifyd Cloud enables the following:

Take a full base backup once a day on the schedule you configure (backup_schedule, default 0 0 * * *).
Continuously archive WAL segments to your bucket as they're produced. This is what makes point-in-time recovery (PITR) possible — without WAL, restore can only land on a base-backup boundary.
Honour the retention policy you configure (backup_retention_policy, default 30d). Backups and the WAL needed to replay through them are pruned together.

Credentials are encrypted at rest with the project's encryption key. They're materialised into a per-service Kubernetes Secret only at deploy time.

The Backups tab

In a Postgres service's detail panel, the Backups tab shows:

A health banner: Backups are healthy, Backups are stale, WAL archiving is failing, Last backup failed, Cluster is provisioning, or Backups not enabled.
Last successful backup — when the most recent base backup completed.
First recoverability point — the earliest moment you can recover to. Anything before this is no longer reachable because the WAL has been pruned.
Destination — the bucket path WAL and base backups are written to.
Recent backups — the most recent base-backup runs, with phase, start time, duration, and any error.

Each completed row also has a Restore action, and (when there's at least one recoverability point) a Restore to point in time… button sits above the table.

Recovery window

The recoverability window runs from the First recoverability point to now. Inside this window:

A specific backup restore lands at the moment that backup finished.
A point-in-time restore lands at the exact instant you pick — the platform finds the latest base backup at-or-before that instant, then replays WAL up to it.

If you pick a target outside the window, the API rejects the request with a clear message naming the window's bounds. (We don't replay WAL we don't have.)

Restore to a specific backup (one click)

Open the Postgres service → Backups tab.
Find the row you want in Recent backups. Only completed rows are restorable.
Click Restore on that row.
The Create Postgres Database dialog opens with a banner naming the source service and backup ID. You only choose Storage and Deployment type — credentials and bucket details are reused from the source service.
Click Create. A new Postgres service appears in the canvas and bootstraps from the backup. When the row turns green, the database is ready.

The original service is untouched throughout.

Restore to a point in time (PITR)

Open the Postgres service → Backups tab.
Click Restore to point in time… above the table.
The dialog shows the recovery window and a datetime picker, defaulted to the latest reachable instant.
Pick the moment you want to recover to (e.g. one second before that bad migration ran).
Choose storage and deployment type. Click Create.

Simplifyd Cloud bootstraps the new cluster from the latest base backup before your chosen time, then replays WAL up to it. The new service appears in the canvas; once it's running, point your application at the new connection string.

Manual restore (advanced)

When you create a new Postgres service from the command palette and toggle Restore from backup, you can paste in source bucket details and credentials directly. This is the path for restoring from a bucket that doesn't belong to a service in this workspace — e.g., a backup taken by an external system. You can also provide an optional Target time alongside (mutually exclusive with Backup ID).

Verifying the restore

Once the new service is running:

Connect with the connection string shown in the service panel.
Run SELECT pg_last_xact_replay_timestamp(); — for a PITR, this should be at-or-just-before your target time.
Spot-check tables you expect to see and tables you don't.

If something looks wrong, the original service is still untouched. Delete the new service and try a different target.

Failure modes

Symptom	Likely cause	Fix
API rejects with `target_time is before the source's first recoverability point`	The target predates available WAL.	Pick a later target, or extend retention before relying on older windows.
New Service logs `requested recovery stop point is before consistent recovery point`	There's no base backup at-or-before the target.	Pick a later target (closer to a known base backup).
Service logs show 403 / `AccessDenied`	Bucket credentials rotated since the source last archived.	Update the backup config on the source first to refresh creds, then retry.
Service logs show timeouts to the bucket	Region mismatch or wrong endpoint.	Pass `region` and (for non-AWS S3) `endpoint_url` in manual restore.

Limits

No cross-major-version restore. The new cluster comes up on the same Postgres major version as the source. To upgrade, restore first, then run a logical dump/load on the new cluster.
Single recovery target only — pick one of: specific backup, target time, target XID, target immediate.
The restore creates a brand-new service in the current environment. You point your app at the new connection string when ready.

PostgreSQL Backup & Restore

On this page