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 a base backup and then replays the WAL forward. On WattleDB, WAL archiving runs continuously on every tier, so the history needed to land between backups is being kept.

What you can pick today. The console's restore form gives you two choices: Latest — the most recent base backup plus all WAL since, which is as close to now as the platform can get — or any completed backup in your window, which recovers the database to the exact state of that backup. There is no free-text timestamp box in the console yet, so on the daily-backup tiers the granularity you can self-serve is the latest moment or yesterday's backup, not an arbitrary 3:59pm. We would rather say that plainly than let you plan a recovery around a control that isn't there.

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 — an hourly base backup means the nearest restore point is never more than an hour away.

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 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.