Code10x
Backups and disaster recoverymedium3-5 years

A team states an RPO of five minutes for their order database, but their backup mechanism is an hourly `pg_dump`, and the dump itself completes in 90 seconds. Does this mechanism actually meet a five-minute RPO, and would making the dump run faster fix the gap?

No, and making the dump faster doesn't help at all. RPO is about the gap between recovery points, not how long any individual backup takes to run — an hourly dump has an RPO of up to roughly an hour, because if the database is lost 58 minutes after the last successful dump, everything written in those 58 minutes is gone, regardless of whether the dump itself took 90 seconds or 9 seconds. A faster dump only changes how long the backup job runs; it does nothing about how much data can be written in the gap between one dump starting and the next one starting. To actually hit a five-minute RPO you need a fundamentally different mechanism — continuous WAL archiving with point-in-time recovery, which captures every committed change as it happens rather than only what exists at the moment a periodic snapshot runs.

The lesson behind it →
PreviousA load test claims p99 latency of 50ms at the target throughput, using a tool that waits for each response before sending the next request. Production, at the same throughput, sees p99 latencies over a second during a brief slowdown. What's wrong with the load test's methodology?Next A migration adds a nullable column — `ALTER TABLE orders ADD COLUMN gift_note text` — which should be a millisecond metadata-only change on PostgreSQL. Instead, an ordinary `SELECT ... WHERE id = ?` on the same table times out after three seconds. There's an idle transaction from a forgotten reporting query sitting open. Walk through exactly why an unrelated, lock-compatible SELECT gets stuck behind this.