What is RPO?
It is the question most teams skip until a database dies: how much of today's work can you afford to redo by hand?
Recovery point objective (RPO)
RPO
Recovery point objective, or RPO, is the maximum data a system may lose after a failure, stated as a length of time. An RPO of one hour means the worst case is redoing the last hour of work, not the whole day.
RPO answers a different question than uptime does. Uptime asks how long a system can be down. RPO asks how much of what happened right before the failure is gone for good, because the backup is older than that.
The number is a business decision, not a technical default. A blog can tolerate a day of lost drafts. A checkout system losing an hour of orders means real refunds and real customers to call. The RPO should come from what an hour of missing data actually costs, not from whatever the backup schedule happens to be.
Why the number needs to be decided, not inherited
Most systems get an RPO by accident. Someone set up nightly backups two years ago and nobody has revisited it since. That gives a 24-hour RPO whether or not a day of lost orders is something the business can absorb.
A stated RPO forces the opposite order. You decide how much loss is survivable first, then pick a backup interval that meets it. Point-in-time recovery can bring that down to seconds. A nightly dump caps it at a day, whatever else the system does well.
On systems we maintain, we test restores on a schedule rather than trusting that a backup job running green means a backup that works. A restore that has never been run is the most common way an RPO turns out to be fiction on the day it is needed.
- Last good backupThe point you can actually recover to.
- Data keeps changingOrders, edits, writes pile up.
- Failure hitsDisk, deploy, deletion, or attack.
- Restore runsEverything after the backup is gone.
- Gap measuredThat gap is the real RPO, not the target.
The RPO you wrote down and the RPO you get are only the same number if someone has actually restored from that backup.
Common questions
01What is the difference between RPO and RTO?
RPO measures data loss, in time since the last good backup. RTO measures downtime, in how long the system stays unavailable during recovery. A system can have a tight RPO and a slow RTO: almost no data lost, but hours before anyone can use it again. See recovery time objective for the full pairing.
02How do you actually measure RPO?
As the gap between the moment of failure and the last backup you could realistically restore from. A nightly backup at 2am and a failure at 6pm gives a real RPO near 16 hours, not the 24 the schedule implies. The gap depends on when failure happens too.
03What RPO does a small business actually need?
Whatever amount of redone work is genuinely tolerable, priced in hours someone would spend re-entering orders or re-uploading files. A content site can often live with a day. A system taking payments or scheduling jobs usually cannot, and needs point-in-time recovery instead of a nightly dump.
04Does Postgres support a tight RPO?
Standard Postgres supports point-in-time recovery through continuous WAL archiving, which can bring RPO down to seconds instead of a day. Supabase runs on standard Postgres, so the capability is there. Whether it is configured and actually tested is a separate question from whether it is available.
