Point in Time Recovery: A Founder's Insurance Policy

What you need to know

• PITR protects against the most common data disaster scenario: accidental deletion or corruption discovered hours or days after it happened, when regular backups have already overwritten the pre-incident state.
• Most managed database platforms include PITR as a feature. Enable it and verify the retention window before the product goes to production users.
• PITR recovery should be tested before it is needed. Knowing how to restore to a specific point in time under pressure is different from knowing that the feature exists.
• The retention window should be at least 30 days for any production database with real user data. A 7-day window means a data incident discovered on day 8 is unrecoverable.
• PITR does not protect against all data loss scenarios. It does not recover from deleted database instances (only the WAL and backups survive), infrastructure-level corruption, or incidents outside the retention window.

The core argument

Database backups are standard practice for any responsible SaaS operation. PITR is the upgrade that makes those backups actually useful for the most common recovery scenarios. The problem with daily snapshots is that most data incidents are not discovered at the moment they occur. A bad migration that corrupts a subset of records, a bug that silently deletes user data, or an administrative action that deletes the wrong records are typically discovered hours or days later. By the time the incident is identified, the daily snapshot has already been overwritten by the corrupted state.

PITR solves this by allowing recovery to any point before the incident, even if that point is 15 days ago. The database is not restored to yesterday's snapshot; it is restored to the specific minute before the bad migration ran, or the specific hour before the bug caused deletions. The data loss is measured in seconds rather than in hours or days.

For founders running production SaaS products, PITR is one of the highest-value infrastructure features to enable relative to its cost. The cost of PITR on most managed database platforms is included in the standard platform subscription or adds a small monthly cost for additional WAL storage. The cost of a data loss incident without PITR is potentially catastrophic: user data that cannot be recovered, customer trust that is irreparably damaged, and regulatory obligations that cannot be met. In my experience, the founders who have experienced a data incident without PITR always wish they had enabled it.

Common mistakes

1. Not verifying that PITR is enabled after account setup. Managed database platforms often have PITR enabled by default but with a 7-day retention window. Verify the configuration explicitly and extend the retention window to 30 days before the product receives any user data.

1. Not testing restoration before an incident occurs. PITR documentation describes the process; testing reveals the actual recovery time and any configuration issues. Run a test restoration to a recent timestamp on a non-production database to verify the process works and to measure the recovery time.

1. Not documenting the PITR restoration procedure. The restoration procedure should be documented in the runbook and accessible to every engineer who might need to execute it. An incident at 2am is not the time to figure out the restoration commands for the first time.

1. Confusing PITR with disaster recovery. PITR protects against data corruption and accidental deletion within the retention window. It does not protect against the database instance being deleted, the cloud provider region going down, or infrastructure-level failures. Disaster recovery requires cross-region replication or backups stored in a different provider.

1. Treating PITR as a substitute for data validation. PITR enables recovery from data incidents; it does not prevent them. A schema migration that corrupts records should be prevented by testing the migration in staging first and by having a rollback plan. PITR is the last resort, not the first defense.

Where to start

1. Verify PITR configuration on all production databases. Log in to the database platform and confirm: PITR is enabled, the retention window is at least 30 days, WAL archiving is active. For self-managed Postgres, verify that WAL-G or pgBackRest is configured and that WAL files are being archived to remote storage.

1. Test a restoration to a specific point in time. Use a development or staging environment copy of the production database. Select a target timestamp from the past 24 hours. Execute the restoration procedure. Verify that the restored database contains the expected state at that timestamp.

1. Document the restoration procedure in the engineering runbook. Write the step-by-step process for restoring the production database to a specific point in time. Include the commands, the expected output, and the verification steps. Store this document where it is accessible to all engineers.

Related reading

• Observability in 2026: Metrics, Logs, Traces
• Incident Severity Levels: A Practical Definition
• Multi-Region Deployments: Decision Framework and Cost Math
• PostgreSQL Performance at Scale: The Tweaks That Move the Needle