SaaS disaster recovery gets treated as a checkbox: yes, we have backups, next question. That framing survives right up until the moment something actually breaks, and then RPO and RTO stop being acronyms on a slide and start being the difference between an incident and a company-ending one. I've built and maintained multi-tenant SaaS in production long enough to know the gap between "we have a backup" and "we can actually recover" is where most disaster recovery plans quietly fail.
Key Takeaways
- RPO measures how much data you can afford to lose, RTO measures how long you can afford to be down. Neither number means anything until you've tested the recovery, not just the backup.
- A nightly snapshot is not a disaster recovery plan. It is one input to one.
- Restoring a single tenant out of a shared Postgres database usually means restoring the entire database to a throwaway instance first, then extracting the one tenant you actually need. There is no native "restore just this customer" command for a pooled schema, and most teams learn that mid-incident instead of beforehand.
- Point-in-time recovery products differ more than they look. Some replay a base backup plus write-ahead logs; Neon's restores from continuous branch history instead, which changes the math on RTO.
- Only 28% of organizations hit by ransomware in 2026 fully recovered all their affected data, per Veeam's Data Trust and Resilience Report. Confidence and actual recovery are not the same thing.
- Test your restore path on a schedule you'll actually keep, not the one that looks good in a compliance document.
What Do RPO and RTO Actually Mean for a SaaS Team?
RPO is the maximum data loss you can tolerate, measured backward in time from the incident. RTO is the maximum acceptable downtime before the business impact becomes real. Most teams learn both terms from a vendor's marketing page and then never revisit what number actually fits their product.
For an early-stage B2B SaaS, the honest RPO conversation usually starts at 24 hours, not zero. A daily automated backup on managed Postgres is enough for a huge share of products that aren't processing real-time financial transactions. Point-in-time recovery, where you can restore to a specific second rather than the last nightly snapshot, per the PostgreSQL project's own documentation on continuous archiving, is a real upgrade over daily snapshots. It is also not free, and it is not automatically the right first purchase.
Supabase, for instance, prices PITR as a paid add-on: roughly $100/month for a 7-day retention window on the Pro plan, billed hourly, with longer windows up to 28 days on higher tiers. The part people miss is that PITR spend sits outside your account's spend cap entirely. You can budget carefully for everything else and still get a surprise line item from the one feature that's supposed to protect you from surprises.
Why a Nightly Backup Is Not a Disaster Recovery Plan
A backup is a file. A disaster recovery plan is a tested procedure that turns that file back into a running application within a time window someone actually agreed to. Those are different products, and treating the first as a substitute for the second is the single most common mistake in this space.
Picture the actual moment this matters: 2am on a Saturday, the primary database is unreachable, and the on-call engineer is three tabs deep into a runbook written for infrastructure that changed eight months ago. Nobody in that room cares that a backup file exists somewhere in cold storage. They care whether the restore command in front of them still works.
You've probably confirmed a backup exists. Have you actually run the restore, end to end, on infrastructure that resembles production? Most teams answer no. The honest ones will tell you it's been over a year since the last real test, if there ever was one. A genuinely bad time to find out.
How Do You Restore a Single Tenant From a Shared Database Backup?
Restoring one tenant from a shared Postgres database usually means restoring the whole database to a temporary instance first, then extracting and reloading just that tenant's rows. There's no native "restore this one customer" command for a pooled schema.
AWS's own guidance on multi-tenant backup and recovery lays out the trade-off plainly: you can segregate tenant data at backup time, which is faster to restore later but multiplies your backup operations by tenant count, or you defer that cost to recovery time, spin up a temporary database from the full snapshot, pull the one tenant's data out, and tear the temporary instance down. The second approach is cheaper day-to-day and slower exactly when a customer is on the phone asking why their data disappeared.
The instinct here is to reach for database-per-tenant so a single restore stays clean and self-contained. Actually, that overstates the case: database-per-tenant multiplies your backup jobs, your monitoring, and your patching by tenant count, and most teams reach for that isolation well before any customer has actually asked for it.
On Callidus, the clinic SaaS I built on Firestore rather than Postgres, tenant isolation lives at the path level (tenants/{tenantId}/...), and the retention question showed up differently: audit log entries carry a three-tier TTL, ninety days for routine events, one year for financial ones, two years for anything GDPR-sensitive, with permanent retention only for a hard-erasure record. That's not a disaster recovery number, it's a retention policy, but the underlying decision is the same one you're making with a PITR window: how far back do you actually need to reach, and who is paying for the storage while you decide.
Postgres PITR vs Managed Backups vs Branch-Based Restore
Not every "point-in-time recovery" product works the same way underneath, and the difference changes your real-world RTO.
| Approach | How it recovers | Typical RTO | Typical cost model | |---|---|---|---| | Self-managed WAL archiving | Restore a base backup, replay WAL to a target LSN or timestamp | Hours, scales with data size | Storage cost only, but real engineering time to operate | | Supabase PITR | Restore to a chosen second within a paid retention window | Minutes to an hour, depends on database size | ~$100–400/month by retention window, billed hourly, outside spend cap | | Neon branch-based restore | Restore from continuous branch history, no base-backup replay | Near-instant for most sizes | Included by tier; default history window is 6 hours on Free, 1 day on Launch/Scale, extendable on paid plans |
Neon's own write-up on point-in-time restore is explicit that this isn't the classic snapshot-plus-replay model at all — it's a branch operation against continuously retained history, including schema changes. The default retention windows are documented separately: six hours on Free and one day on Launch and Scale, per Neon's history window documentation, with longer windows available on paid plans. That's a genuinely different recovery primitive than the traditional approach described in the PostgreSQL documentation, and it's recent enough that a lot of SaaS teams are still architecting around the old assumption that PITR means "restore a backup and wait."
The Backup-Rot Problem Nobody Tests For
Backups accumulate long after anyone remembers why. Old tenant data, deprecated schemas, tables nobody queries anymore, all faithfully backed up forever, quietly inflating your restore time and your storage bill. A leaner retention policy, decided on purpose rather than by default, is usually worth more than a longer one.
What RPO and RTO Should an Early-Stage SaaS Actually Target?
An early-stage SaaS should target an RPO of 24 hours and an RTO of a few hours, not the near-zero numbers enterprise vendors advertise. Chasing sub-minute RPO before you have the customer contracts that require it just spends engineering time you don't have on a guarantee nobody's asking for yet.
That said, don't confuse "realistic for your stage" with "untested." In Veeam's 2026 Data Trust and Resilience Report, which surveyed over 900 security leaders, only 28% of organizations hit by ransomware fully recovered all their affected data, and the average organization recovered just 72% of what was affected. Confidence in an RTO and a validated RTO are not the same claim, and the gap between them is exactly where an incident actually costs you money. If you're picking your first stack for a SaaS build, the recovery story is part of what the SaaS MVP stack decision should account for, not something bolted on after the first customer complains.
A Disaster Recovery Testing Cadence That Actually Happens
Pick a cadence you'll keep, not the one that reads best in a compliance document.
- Quarterly, restore your most recent backup to a throwaway environment and confirm the application actually boots against it, not just that the file decompresses.
- Once a year, simulate the worst case you can reasonably imagine: full region loss, corrupted primary, or a single-tenant restore under time pressure, and time the whole thing.
- After every schema migration, re-verify that your restore procedure still matches the current schema. A restore script written for last year's tables is a plan for last year's database, not this one.
- Document the actual RTO you measured, not the one you hoped for, and update the number leadership sees.
- Rotate who runs the drill. The person who wrote the runbook is the worst test of whether the runbook actually works for someone else at 2am with less context than they had.
None of this requires an enterprise budget. It requires deciding, on purpose, what your RPO and RTO actually are for the stage you're at, picking tooling that matches that number rather than the biggest number a vendor will sell you, and running the restore often enough that the first real test of your disaster recovery plan isn't an actual disaster.
If you haven't restored a backup in the last quarter, that's this week's task, not next quarter's.