Guide
Logical vs physical backups on managed databases
pgBackRest and WAL-G are the gold standard for Postgres backups — and you usually can't run either on a managed cluster. Here's the difference, why managed databases push you toward logical dumps, and what that trade-off actually costs you.
The two kinds of backup
Physical backups copy the database's files on disk — the actual data blocks and the write-ahead log (WAL). Tools like pgBackRest, WAL-G and Barman do this, usually with continuous WAL archiving for point-in-time recovery. They are fast, incremental, and restore the entire cluster byte-for-byte.
Logical backups export the database's contents — the SQL to recreate schemas, tables and rows. pg_dump / pg_dumpall for Postgres, mysqldump for MySQL. The output is a portable file, not a copy of the storage.
| Physical (pgBackRest, WAL-G) | Logical (pg_dump) | |
|---|---|---|
| Granularity | Whole cluster | Per database, per table |
| Point-in-time recovery | Yes (WAL replay) | To the dump's timestamp |
| Portable across versions/providers | No (same major version, same layout) | Yes |
| Restore speed on huge data | Fast (block copy) | Slower (replays SQL, rebuilds indexes) |
| Access needed | Filesystem + WAL + superuser | Connect + SELECT |
| Runs on managed databases | Almost never | Yes |
Why physical tools can't run on managed databases
Physical backup tools need things a managed provider deliberately doesn't give you:
- Filesystem access to the data directory — you don't get a shell on the box.
- WAL archiving hooks (
archive_command, replication slots, or aSUPERUSER/replication role) — locked down on managed plans. - A matching restore target — a physical backup restores only to the same major version and storage layout, which you don't control on someone else's cluster.
The provider runs its own physical backups internally — that's what powers their point-in-time restore. But you can't drive those tools yourself, and the provider's restore is cluster-only and non-downloadable. So for a backup you own and can move, logical is the realistic option.
What logical backups cost you — and how to manage it
Logical dumps have real trade-offs; none is fatal for most managed workloads:
- Recovery point is the dump time. A nightly dump means up to ~24h of potential loss. Mitigate by dumping more often (hourly on hot databases) — cheap when each database is small.
- Restore replays SQL and rebuilds indexes, which is slower than a block copy on very large data. For per-tenant databases in the tens of GB this is minutes, not hours.
- Consistency. Use
--single-transaction(MySQL) or rely onpg_dump's consistent snapshot (Postgres) so a dump is a coherent point, not a smear.
In exchange you get the two things physical backups can't offer on managed infra: per-database granularity and portability. You can restore one tenant without touching the rest, and load the dump anywhere.
dbferry does logical, per database, done right
dbferry takes a consistent logical dump of each database on your managed cluster, compresses and encrypts it client-side, and streams it into your own bucket on a schedule — hourly or nightly, with GFS retention. All the operational parts (fan-out, retention, alerts, dead-man's switch) handled, none of the physical-access requirements you can't meet.