Home / Guides / Single-tenant restore vs pg_dump vs PITR
Single-tenant restore vs pg_dump vs PITR
"Why not just use pg_dump or point-in-time recovery?" is the first question every engineer asks about single-tenant restore. It's a fair one — and the answer is that they solve a different problem. Here's the honest comparison.
Postgres already ships excellent recovery tools. The distinction that matters isn't quality — it's granularity. pg_dump and PITR operate on the whole database or whole tables. Single-customer recovery operates on the application's tenant boundary, which cuts across tables. They're complementary, not competing.
| pg_dump / pg_restore | PITR (WAL replay) | Single-tenant restore | |
|---|---|---|---|
| Unit of recovery | Database or table | Whole cluster to a timestamp | One tenant's row + file closure |
| Affects other tenants | Yes (whole DB/table) | Yes (rolls back everyone) | No — others stay live |
| Follows FKs across tables | No (per-table) | N/A (whole DB) | Yes — resolves the graph |
| Covers object storage | No | No | Yes — blob + S3 keys |
| Safe live merge-back | Manual | Not applicable | Hash-pinned plan + approval |
| Best for | Full backups, migrations | Cluster-wide disaster recovery | Recovering / erasing one customer |
Where pg_dump stops
pg_dump is per-table. You can dump a table with a WHERE filter, but a tenant isn't one table — it's rows scattered across dozens of tables joined by foreign keys, composite keys, and denormalized columns. Reassembling one customer from per-table dumps means hand-writing the join graph yourself, and it still ignores files in object storage.
Where PITR stops
Point-in-time recovery is the right tool when the whole cluster needs to go back to a moment before a disaster. But if only one customer was affected, PITR's all-or-nothing rollback throws away every other tenant's legitimate writes since that timestamp. You recover one customer by harming all the others.
What single-tenant restore adds
It treats the tenant closure as the unit of recovery: resolve the graph, extract one customer's rows and files, diff against live data, then merge back under a hash-pinned plan that verifies non-target tenants stayed unchanged. Crucially, it uses your existing backups — you still restore a PITR snapshot to scratch; single-tenant restore is the layer that carves one customer out of it safely.
The short version: keep pg_dump and PITR for what they're great at. Add single-tenant restore for the one thing they can't do — recover, export, or erase one customer without touching the rest.
See it on your own schema
Send a schema, a backup description, and one representative tenant. TenantUndo returns a recovery map, the failure points, and a signed drill report.
Run a recovery drill