Point-in-time recovery: getting your data back

Backups are the first thing everyone sets up and the last thing anyone tests. The gap that bites is granularity: if all you have is last night's dump, then any mistake made during the day costs you the whole day's data. Point-in-time recovery (PITR) closes that gap — and it's on every WattleDB tier. Here's what it actually gives you.

How PITR works

PITR combines two things: a periodic base backup of the whole database, and a continuous stream of write-ahead log (WAL) records capturing every change since. To recover, the system restores the base backup and then replays the WAL up to the exact moment you choose. That's what lets you land on 3:59pm instead of last midnight.

Your recovery window

How far back you can go depends on your tier. Every WattleDB database — on every tier — gets daily backups and point-in-time recovery. The Scale tier steps that up to hourly backups with a 30-day recovery window, so higher-value databases can be rewound with finer granularity over a longer period. You pick the moment; the platform holds the history to make it reachable.

Restore to a new database, not over the old one

When you recover, WattleDB restores into a new database rather than overwriting the original. This matters more than it sounds: after an incident you often want to compare the recovered state against the current one, extract just the rows that were lost, or verify the restore before cutting over. Overwriting in place destroys your ability to do any of that. A fresh database keeps both versions in hand until you're sure.

Cross-state by design

A backup in the same building as the database it protects isn't much of a backup. WattleDB runs its primary infrastructure in Sydney and holds backups cross-state in Melbourne — so a single-city incident can't take out both your database and its recovery point. Backups are encrypted at rest, and they never leave Australia.

What PITR protects against — and what it doesn't

PITR is your recovery from operational disasters: a bad migration, an accidental DELETE, a buggy batch job, a corruption event. Rewind to just before it happened and you're back. What backups and PITR can't fix on their own are access-control mistakes — data exposed to the wrong user isn't un-exposed by a restore. That's the job of Row-Level Security. Together they cover both halves: RLS stops the bad thing, PITR undoes it.

Test your recovery before you need it

The one habit that separates teams who survive incidents from those who don't: actually running a restore before a real emergency. Because WattleDB restores into a new database, you can rehearse recovery any time without touching production — do it once, confirm the data's there, and you'll trust the button when it counts.