Point-in-time recovery (PITR) is the PostgreSQL recovery workflow for restoring a database to a specific moment before an error, deletion, or incident. It relies on a base backup plus archived WAL records that replay changes up to the chosen recovery target.
PITR is not just a checkbox in a backup policy. Teams need to know whether they can find the right recovery target, restore successfully, validate the restored state, and decide how to move data or traffic afterward.
How PITR Works in PostgreSQL
PostgreSQL writes changes to WAL before those changes are considered durable. A PITR workflow starts from a base backup and replays WAL records until a configured recovery target, such as a timestamp, transaction ID, or named recovery point.
The restore process reconstructs the database state as it existed at that target. The difficult part is often not the mechanics of replay; it is choosing the right point, verifying the result, and deciding how to recover affected data safely.
Where Teams Use PITR
PITR is useful when the desired recovery state is not simply the latest backup. It helps with accidental deletes, bad migrations, data corruption windows, and application releases that wrote incorrect data over a short interval.
Common patterns include:
- recovering from accidental table updates or deletes
- replaying to the moment before a bad migration
- validating RPO and RTO assumptions during restore drills
- creating a side environment for forensic review
- testing whether archived WAL coverage is complete
Need to validate Postgres recovery without touching production? Use Vela branches and clones to rehearse recovery workflows and inspect restored states before making production decisions. See Vela database branching
PITR vs Backup Restore vs Branch-Based Validation
PITR answers a different question than a normal backup restore: not simply whether a database can be restored, but whether it can be restored to the right moment.
| Approach | How it works | Best fit | Common limitation |
|---|---|---|---|
| Latest backup restore | Restores the most recent backup artifact | Simple recovery and restore drills | May include unwanted changes after the incident |
| PITR | Base backup plus WAL replay to a target | Recovering to a precise moment | Requires WAL coverage and target selection |
| Branch-based validation | Inspect a restored or branched state before action | Rehearsal, forensics, and safe review | Needs clear promotion or repair process |
| Shared staging restore | Restores into a long-lived shared environment | Occasional manual testing | Can drift and is hard to keep reliable |
How PITR Relates to Vela
Vela does not remove the need to understand PostgreSQL recovery concepts. WAL, base backups, recovery targets, and validation still matter. Vela is relevant because teams often need safe environments to inspect, test, or rehearse recovery decisions.
A branch or clone can give incident responders a safer place to validate data state and recovery assumptions before changing production or asking application teams to switch traffic.
Operational Checks
Before relying on PITR for production, verify the full recovery path:
- confirm base backups and WAL archives cover the required recovery window
- run restore drills against realistic data volume
- document how teams choose and verify recovery targets
- test application behavior against restored state
- define who approves promotion, repair, or data extraction after restore
Related Vela Reading
Start with How Vela Works, Database Branching, Branch per PR, and the Vela articles library. For adjacent glossary terms, review Base Backup, pg_basebackup, Recovery Target, Database Branching.