The short version

If you run a small SaaS on Postgres, the backup question is not whether to back up — it is which combination of tools and frequencies matches the data you would actually miss. Three approaches cover almost every indie setup:

  • Managed snapshots — your database host (or a managed Postgres service) takes regular copies for you.
  • Logical dumps via cron — a scheduled pg_dump (or the platform equivalent) writes a portable file you control.
  • Point-in-time recovery (PITR) — the database keeps a rolling log so you can restore to any moment, not just to “last backup”.

Most teams will not pick just one. The combination that tends to fit a small SaaS is: a daily managed snapshot as the safety net, a daily pg_dump you can grab and move, and PITR turned on if your host offers it cheaply.

The rest of this guide explains why, how often is realistic, and the one habit that turns a backup from a folder of files into something that can actually save your business: restoring one on purpose, on a schedule.

Why this is a founder problem, not just a DBA problem

Backups feel like plumbing until the day you need them. Then they are the only thing standing between you and a customer-trust event. For a solo founder or small team, a database loss shows up as three things at once:

  • Downtime your paying users notice in real time.
  • Reputation damage that is hard to undo on a small customer base.
  • Lost work — every event, signup, integration, and record your app has collected.

Because the team is small, you do not have a separate ops person to discover the problem. You are also the one who has to choose the tool. That is why this is a purchasing decision dressed up as a technical one: you are choosing between managed infrastructure, a small script on a schedule, and somewhere in between.

The three approaches, explained in plain language

1. Managed snapshots (the “the host handles it” option)

Most managed Postgres services and most major cloud databases can take automated snapshots on a schedule — daily, hourly, sometimes continuously. They live in the provider’s storage, often in a different availability zone.

Why founders like them:

  • Set-and-forget. You configure it once.
  • Snapshots are usually consistent at the storage layer, so you do not worry about a half-written transaction.
  • Restoring is one or two clicks in a dashboard.

The honest trade-offs:

  • You depend on the provider’s retention window. If they keep seven daily snapshots and the corruption is eight days old, you are out of luck.
  • Restoring often means restoring the whole cluster, not one table.
  • You are trusting one vendor for both the database and the copy. If their account is compromised, both can go.
  • Cost scales with database size and retention, which can quietly grow on you.

A snapshot alone is rarely enough for a small SaaS. It is the right floor — but not the ceiling.

2. Logical dumps with pg_dump and a schedule (the “portable file you own” option)

pg_dump is the built-in Postgres tool that exports your database as a script or compressed archive. It is the most portable backup Postgres can produce: the output can be loaded into a different Postgres version, on a different host, on a different cloud.

Why founders like it:

  • The output is a regular file you can copy to anywhere — object storage, another region, your laptop for staging.
  • Selective: you can back up one database or one schema, not just everything.
  • Cheap: the tool is free; storage is usually pennies per gigabyte.
  • Easy to script with cron, GitHub Actions, or a scheduled container.

The honest trade-offs:

  • Restores are slower than restoring a snapshot, because Postgres has to replay SQL or rebuild from an archive.
  • The database has to be online to run pg_dump. That is normally fine, but it matters for very large databases where the dump window starts to bite.
  • A logical dump does not give you point-in-time recovery. You get whatever was true at dump time — nothing in between.

For an indie app up to a few gigabytes, a daily pg_dump is fast, cheap, and quietly reassuring.

3. Point-in-time recovery (PITR) (the “rewind the clock” option)

PITR is the ability to restore the database to any specific moment, not just to “the last backup”. Under the hood, it works by combining a base snapshot with a continuous stream of write-ahead log (WAL) records. Most managed Postgres services offer PITR as a paid add-on, and the open-source tool pgBackRest is a popular way to get it on self-hosted Postgres.

Why PITR matters for small SaaS:

  • A bad migration at 2pm no longer means restoring last night’s dump and losing a full day of work.
  • Ransomware or a fat-fingered DELETE becomes a 15-minute incident instead of a business-ending one.
  • The recovery point you advertise to customers can be hours, not days.

The honest trade-offs:

  • PITR usually costs extra — either a feature fee with a managed provider, or real engineering effort if you self-host with pgBackRest.
  • You still need snapshots and WAL archives; PITR is a layer on top, not a replacement.
  • Retention is still finite. If your WAL archive only goes back 7 days, you cannot rewind further.

A realistic backup schedule for a small SaaS

“How often should I back up?” is the wrong first question. The right first question is: how much work am I willing to lose?

  • A 10 GB customer-data app that loses a day of signups has a very different answer than a transactional system that loses an hour of payments.
  • Pick a recovery point objective (RPO) — the maximum data you would tolerate losing — and work backward.

A practical starting point for a small SaaS:

Tier Frequency Tool Why
Floor Daily Managed snapshot The provider’s safety net.
Portable copy Daily pg_dump to object storage A file you own, off the host.
Granularity (optional) Continuous WAL PITR Rewind to any moment.
Deploy-time Per release Triggered dump before migrations Cheap insurance during risky changes.

If PITR is too expensive right now, daily snapshot + daily pg_dump is a respectable baseline. If a day’s worth of signups would genuinely hurt, add PITR — that single upgrade often changes the whole risk profile.

The habit that matters more than the tool: restore drills

A backup you have never restored is a hope, not a plan. The single biggest failure mode for small teams is finding out, during an outage, that the backup is corrupt, the wrong database, the wrong region, or the restore script does not work on the current Postgres version.

A simple routine that actually holds:

  1. Quarterly, restore your latest dump into a fresh database. Use a different name, a different host if possible, and a recent Postgres version. Time it.
  2. Compare row counts on the most important tables (users, orders, events). They do not have to be identical to the second, but the trend should be sane.
  3. Try a PITR restore if you use it — restore to a moment ten minutes ago, confirm you can connect, then drop it.
  4. Document the time it took. You now have a real number for your recovery time objective, not a guess.
  5. Keep credentials and scripts in the same place you would look during an actual incident. A password manager entry labeled “DB restore runbook” is enough.

Treat a failed restore as the alert it is. A broken backup pipeline is not a thing you fix later; it is a thing you fix today.

Where the storage target matters

Backups that sit in the same account, same region, or same provider as your database are vulnerable to the same incidents — account compromise, regional outage, accidental deletion of the whole project. Move them out.

For a small SaaS, an object storage bucket in a different provider or region is usually enough. Encrypt the files, restrict the bucket, and version it so a bad script cannot quietly overwrite every backup you have.

A founder’s checklist before you choose

  • What is my RPO? Hours, or minutes? This decides whether PITR is worth the spend.
  • What is my RTO? How long can the app be down before customers churn?
  • Where do the backups live? Same account as the database, or somewhere separate?
  • Who can restore them? Just you, or someone else on the team?
  • When did I last prove I could restore? If the answer is “never”, that is the first problem to solve.

You do not need a perfect system on day one. You need a documented one that you have actually exercised.

Frequently asked questions

Is a managed snapshot enough on its own? It is a sensible floor, but it concentrates risk with one provider and usually does not give you point-in-time recovery. Pairing it with an off-host pg_dump is the common indie setup.

How often should I run pg_dump? For most small SaaS apps, daily is a reasonable default. Increase it if your app writes a lot of important data per hour, or if a day’s worth of loss would meaningfully hurt customers.

Do I really need PITR for a small app? Not necessarily. If a daily dump is enough recovery granularity for the value your app creates, skip it. If you process payments, sign contracts, or store user-generated content continuously, PITR tends to pay for itself the first time you need it.

Where should I store the dump files? Outside the database account, in encrypted object storage with versioning enabled. The point is that a single account-level failure cannot wipe both the database and its backups.

Sources