Skip to main content
Point-in-time recovery (PITR) lets you restore a Postgres database to an exact moment, for example one second before a bad migration or an accidental DELETE. Brimble saves every change to a bucket you own as it happens, so you’re not limited to the times a backup happened to run. A restore never touches the original database. It creates a new database with the data as it was at the moment you pick, and you point your app at it when you’re ready.

​
Availability

Other database engines don’t support PITR yet. You can still restore them from regular backups.

​
How it works

Once PITR is on, two things are saved to your bucket:
  • Every change, continuously. Postgres writes each change to its write-ahead log (WAL). Each finished WAL segment is uploaded to your bucket within about a minute.
  • A full backup once a day. This is the starting point a restore replays the changes on top of. Brimble takes the first one right after you turn PITR on and keeps the 8 most recent.
To restore, Brimble starts a new database from the most recent full backup before your target time, then replays the saved changes up to the exact second you chose. Everything lives under one folder in your bucket:
Because the files are in a bucket you control, you can see them, keep them for as long as you like, and they stay put even if something happens to the database itself.

​
Before you start

  • Choose your own bucket for backups. PITR needs your database’s backup destination to be a Brimble bucket or an external bucket, not the default Brimble-managed storage. Open the database, go to Backups & Restore, click Configure backups and pick a bucket. See backups for the options.
  • Automatic backups turn off while PITR is on. The daily full backup that PITR takes replaces them. You can still take a backup by hand at any time.

​
Turn on point-in-time recovery

  1. Open the database and go to Backups & Restore.
  2. Click Configure PITR.
  3. Click Turn on and confirm.
Brimble takes the first full backup straight away. The restore window starts once it finishes, usually within a few minutes. Until then the drawer shows Taking the first backup…. Most databases switch PITR on without a restart. High-availability clusters, and databases created before PITR was available, restart once to start saving changes. Once it’s on, Backups & Restore shows a note with the earliest moment you can restore to.

​
Restore to a point in time

  1. Open the database and go to Backups & Restore.
  2. Click Restore to a point in time.
  3. Pick the moment. Drag along the timeline, type a date and time, or use a shortcut like 5 min ago or 1 hour ago. The timeline runs from your earliest restore point to now, and the time is shown in your local timezone and in UTC.
  4. Optionally change the New database name. It defaults to <name>-restored.
  5. Click Restore to this moment.
The new database is usually ready in a few minutes. The restore shows up in the database’s history as Point-in-time restore, with an Open link to the new database once it’s done.

​
What the restored database gets

The new database matches the original:
  • The same Postgres version, region, CPU, memory and disk size.
  • The same high-availability setup. A three-member cluster restores into a three-member cluster.
  • The same TLS, public access and IP allowlist settings.
  • The same username and password.
It gets its own connection details. Nothing changes for apps connected to the original until you point them at the new one.

​
Switch your app over

  1. Check the restored data, for example with the database workbench or psql.
  2. Update your app’s connection string to the new database. If the app uses a linked database, link the restored one instead.
  3. Redeploy the app.
  4. Once you’re happy, delete the original database, or keep it for comparison.
If you only need a few rows back, you don’t have to switch at all. Connect to the restored database, copy the data you need into the original, then delete the restored one.

​
Turn off point-in-time recovery

Open Backups & Restore, click Restore to a point in time, then Turn off. Brimble stops saving changes and turns automatic backups back on. Files already in your bucket stay there. Delete the <database-id>/pitr/ folder yourself if you no longer need it.

​
Manage point-in-time recovery from the CLI

The Brimble CLI has the same controls under brimble db pitr:
See Databases in the CLI for external buckets and every flag.

​
Cost

PITR has no separate charge. You pay for the storage it uses in your bucket: Brimble object storage rates for a Brimble bucket, or your provider’s rates for an external one. How much it uses depends on how much your data changes. A database with steady writes stores roughly its full size for each of the 8 daily backups, plus all the changes written in between. Everything is compressed.

​
Limitations

  • The window starts when you turn it on. You can’t restore to a moment before the first full backup finished.
  • Restores create a new database. In-place restores aren’t supported, so the original is never overwritten. Switching your app over is a manual step.
  • One restore at a time per source database.
  • About a minute behind live. The most recent minute of changes may not be uploaded yet.
  • Postgres only for now.
  • Settings can’t change while the database is applying another change, for example a resize. Wait for it to finish, then try again.

​
Troubleshooting

“Point-in-time recovery needs your own bucket.” The database still uses the default backup storage. Choose a Brimble bucket or an external bucket under Configure backups first. “Point-in-time recovery is not available for this database.” The database runs an engine or version that doesn’t support PITR. See Availability. The restore window doesn’t start. The first full backup hasn’t finished. Check that the bucket exists and its credentials are still valid. An external bucket’s access key needs read and write access to the bucket. “A restore is already running for this database.” Wait for it to finish. It shows as in progress in the database’s history. Changes stopped reaching the bucket. If the bucket is deleted or its credentials are revoked, Postgres keeps the unsent changes on its own disk until it can upload them. A long outage uses up disk space. Fix the bucket access, or turn PITR off and on again with a working bucket.

​
Next steps

Last modified on October 25, 2026