Platform
Point-in-time recovery
Restore your database to any second within the retention window — continuous WAL archiving.
Point-in-time recovery (PITR) lets you roll your database back to any moment — e.g. right before an accidental DELETE without a WHERE — with one-second precision. Enable it in Database → Point-in-time recovery.
How it works
- Postgres continuously archives WAL segments, so in the worst case you lose the last couple of minutes on a quiet database.
- A full base backup is taken daily; base backups and WAL are kept for your plan's retention period and copied off-site to Azure Blob Storage.
- Restore: the stack is stopped, a data directory is built from the newest base backup before the chosen moment, and WAL is replayed up to
recovery_target_time. Postgres is then promoted and services start again. - If a restore fails, the previous data directory is kept and the project returns to service.
| Plan | PITR retention |
|---|---|
| Free | not available (daily backups still run) |
| Pro | up to 7 days |
| Team | up to 14 days |
| Enterprise | up to 30 days |
| Item | Value |
|---|---|
| Restore window | from the oldest base backup to the last archived WAL — shown on a timeline in the dashboard |
| Time zone | the dashboard uses Warsaw time; the API and MCP accept and return UTC (ISO 8601) |
| Enabling | a Postgres restart (~10 s) and the first base backup |
| Downtime during restore | a few minutes, depending on database size and WAL volume |
| Scope | the whole Postgres database (including auth and storage metadata). Storage files are not rolled back. |
API
# status and restore window
curl -H "Authorization: Bearer hb_pat_..." https://host.ulewicz.space/api/v1/projects/<ref>/pitr
# enable with 7-day retention
curl -X PUT -H "Authorization: Bearer hb_pat_..." -H "content-type: application/json" \
-d '{"enabled":true,"retention_days":7}' https://host.ulewicz.space/api/v1/projects/<ref>/pitr
# restore to a moment (UTC)
curl -X POST -H "Authorization: Bearer hb_pat_..." -H "content-type: application/json" \
-d '{"target_time":"2026-10-15T12:34:56Z"}' https://host.ulewicz.space/api/v1/projects/<ref>/pitr/restore
MCP offers get_pitr and restore_pitr — the latter requires confirm_ref (the project ref) as a safeguard. A restore overwrites the current database state — to just look at past data, create a branch with data.