COMPARE / CRON + PG_DUMP ↔ OFFSITEDB

“I'll just cron pg_dump”

THE MOST REASONABLE OBJECTION WE GET — TAKEN SERIOUSLY

Every Postgres developer has thought it, and it's not wrong: pg_dump | gzip | aws s3 cp, a cron entry, done. That's a real backup strategy — it's free, you own every byte, and it works on any provider. If you're going to do it, do it well: our pg_dump generator writes the correct flags for your provider. This page is about what the cron job doesn't do, so you can decide with your eyes open.

The five ways the cron job fails on the day it matters

Side by side

Cron + pg_dump

  • Free; full control; provider-agnostic.
  • Monitoring, encryption, retention, restore testing: yours to build and maintain.
  • Knowledge lives in one person's head — fragile to them leaving.
  • Genuinely fine for side projects and replaceable data.

OffsiteDB

  • Same standard pg_dump archives, in your bucket — no lock-in.
  • Every snapshot restore-drilled on real Postgres, row-counted, then sealed.
  • Failure and shrinkage alerts; dead-man monitoring; retention enforced.
  • Tagged pre-migration checkpoints from CI; monthly restore-drill reports.
  • From $9/mo — about one engineer-minute, priced monthly.

The honest decision rule

If the data is replaceable or the project is a hobby, write the cron job — seriously, the generator and the restore-drill checklist will make it a good one. If people pay for the product, the calculus flips: the cron job's true cost is the maintenance and the unproven restore, and both bills arrive at the worst possible moment. (We wrote up that exact Friday.)

FAQ

Is a cron job running pg_dump actually a bad idea?
No — it's a fine idea, and it's how most teams start. The problem isn't day one, it's month eight: the cron silently stops after a credential rotation, nobody notices, and nobody ever test-restored the dumps. The failure mode isn't the script; it's the maintenance nobody budgets for.
I'm comfortable with shell scripts. What am I actually paying for?
Not the pg_dump — the parts around it: restore-drilling every snapshot on real Postgres, alerting the moment a backup fails or stops, encryption and key management, retention enforcement, tagged pre-migration checkpoints in CI, and a monthly report proving all of it. Each is an evening to build and a permanent tax to maintain.
Can I keep my own cron job as a second layer?
Absolutely — independent layers are good. Plenty of users keep a weekly DIY dump alongside OffsiteDB's drilled snapshots. Diversity of backup paths is a feature, not a conflict.
What does OffsiteDB actually store, and can I leave?
Standard pg_dump custom-format archives, gzipped and AES-256-GCM encrypted, in your own bucket. If you cancel, your archives still restore with stock pg_restore — the same restore path your cron job would have given you, minus the lock-in.