Database Backups for Startups: A Founder's Recovery Plan

Most managed databases take one backup a day, which means the worst case on a bad afternoon is losing everything your customers did since the last one. Database backups for startups come down to three decisions: how much data you can afford to lose, how long a restore is allowed to take, and whether anyone has ever tried one. The platform handles the mechanics. Those three answers are yours.

This guide is for founders and small teams running a live product on Supabase, Amazon RDS, Cloud SQL or a similar managed database. It covers what your plan already includes, when point-in-time recovery is worth paying for, what backups quietly leave out, and how to rehearse a restore in an afternoon. If you are heading towards a first launch, this sits beside the other items on our pre-launch checklist for AI-built apps.

Key takeaways

• A daily backup sets your worst case at roughly 24 hours of lost customer work. Decide whether that is survivable before you find out.
• Point-in-time recovery narrows the loss to minutes, but it is a paid add-on and on some platforms it replaces daily snapshots rather than adding to them.
• Restores are neither instant nor invisible. Expect downtime, a new connection string, or both.
• Database backups exclude uploaded files, environment variables and anything held in third-party services such as your payment provider.
• A backup nobody has restored is an assumption. One rehearsal, written down, is worth more than a longer retention setting.

Database backups for startups: what the plan needs to cover

Two numbers and one rehearsal. The numbers are how much data you can lose and how long you can be down; the rehearsal is a restore you have actually performed. Retention settings follow from those answers rather than the other way round.

RPO: how much data you can afford to lose

Recovery point objective (RPO) is the age of the data you end up with after a recovery. If backups run at 02:00 and the database is destroyed at 17:00, your real RPO is fifteen hours of signups, orders, messages and uploads.

For a prototype with ten users, that is an acceptable trade. For a product where customers type in work they cannot reproduce, such as a CRM, a booking system or anything that issues invoices, a full day is usually too much.

RTO: how long recovery is allowed to take

Recovery time objective (RTO) is how long the product can be unavailable while you put it back. Founders tend to underestimate this one, because a restore is not a button that finishes instantly. Supabase's documentation states plainly that the project is inaccessible during a restore and that the time it takes grows with the size of the database.

Write both numbers down in one line each, agree them with whoever answers your support email, and size the plan to match.

Why "we have backups" is not an answer

Because the part that fails is usually the restore, not the backup. AWS's reliability guidance lists the anti-patterns directly: assuming a backup exists, assuming the data inside it is usable, and assuming the restore will finish inside your RTO (AWS Well-Architected guidance on verifying backup integrity).

Each of those is cheap to disprove on a quiet afternoon and expensive to discover during an incident.

Daily backups, point-in-time recovery or your own dumps?

Daily backups are the floor, point-in-time recovery is what you buy when a day of data genuinely matters, and your own dumps are the copy that survives losing the platform account. Most startups should end up running two of the three.

That last row carries a warning. A replica copies your mistakes as faithfully as your data, so it protects against a failed disk and not against a careless DELETE. Counting it as your backup is a common and costly substitution.

When is point-in-time recovery worth paying for?

When an hour of lost data would cost more than the add-on, or when nothing else in your stack could reconstruct what disappeared. PITR works by replaying the database transaction log on top of the last physical backup, so you pick a moment instead of a snapshot date.

The granularity is finer than most founders expect. Amazon RDS uploads transaction logs to Amazon S3 every five minutes, which sets the practical floor on data loss for a point-in-time restore there (Amazon RDS point-in-time recovery documentation).

On Supabase, PITR is priced by how far back you can rewind: roughly $100 a month for 7 days of recovery, $200 for 14 days and $400 for 28 days, and the project also needs at least the Small compute add-on (Supabase database backups documentation). Turning it on stops the daily backups, because PITR already covers that ground.

What does your managed database already do?

More than most teams assume on a paid plan, and in some cases nothing at all on a free one. Check the plan your project is actually on before deciding anything else.

Two details there deserve a second look. Free Supabase projects are not backed up automatically and the documentation recommends regular exports held off-site. And an RDS instance created through the API or infrastructure code defaults to a single day of retention, while setting retention to zero disables automated backups entirely (RDS backup retention settings), so the database your scripts created may be far less protected than the one you clicked together by hand. Cloud SQL leaves retention almost entirely up to you (Cloud SQL backups overview), which also means a thin default is yours to notice.

What backups do not cover

Your database is one of several places your product keeps state, and a database backup restores exactly one of them. The usual gaps:

• Uploaded files. On Supabase the database holds only metadata about stored objects, so restoring an old backup does not bring back files deleted since. Buckets need their own export, and our guide to private buckets and signed URLs covers the access rules around them.
• Secrets and configuration. Environment variables, API keys and provider settings live outside the database. Keep an inventory of where each one is set.
• Custom role passwords. Supabase's daily backups deliberately leave them out, so expect to reset those after a restore.
• Third-party state. Subscriptions at your payment provider, sending domains and DNS all carry on regardless. A restored database can disagree with every one of them.
• The account itself. Deleting a Supabase project removes its backups permanently. One copy outside the platform is the only answer to a lost or suspended account.

How do you test a restore?

Restore into somewhere that is not production, then query it the way a customer would. The first rehearsal takes an afternoon and turns a guessed RTO into a measured one.

1. Pick a target that is not your live project. RDS point-in-time restores create a new instance; Supabase can restore into a duplicate project. Never rehearse on the database serving users.
2. Take a dump you control as well. A logical dump is portable, readable and small enough to keep off the platform.
3. Restore it into a scratch database and watch for errors about missing roles or extensions, which are the two that usually appear first.
4. Check the data, not the exit code. Count rows in the three tables that matter most, point a staging copy of the app at the restored database, and sign in as a test user.
5. Time it. Record how long the whole thing took, from decision to working app, and compare that with the RTO you wrote down.
6. Write the runbook. One page: who gets told, where the backups live, the restore command, how to repoint the app, and what to verify before calling it done.
7. Alert when a backup fails. A job that silently stopped three weeks ago is a classic incident-day discovery, so put that alert wherever your others live; our guide to logging, metrics and alerting on a small team covers the rest of that setup.

The two commands at the centre of steps two and three are short enough to keep in the runbook itself:

pg_dump "$DATABASE_URL" --format=custom --file=backup-$(date +%F).dump

pg_restore --dbname="$SCRATCH_URL" --no-owner backup-2026-10-23.dump

Run the dump on a schedule, keep the output in storage that is not in the same account as the database, and delete old copies on a policy rather than by hand.

When should you take a backup by hand?

Before anything you cannot undo with a second query. Schema changes, bulk updates, a one-off data import, a dependency upgrade that touches the ORM, or letting an AI coding tool edit backend code all qualify.

A manual snapshot taken minutes before the change gives you a known-good point that is minutes old rather than hours. It pairs with the discipline of keeping destructive steps one deploy behind the code that needs them, which our walkthrough of changing a schema without downtime works through in detail.

Common mistakes

• Launching on a free tier that takes no automatic backups and assuming the platform has it handled.
• Treating a read replica as a backup, when it replicates deletions just as quickly.
• Keeping every copy inside one cloud account, so losing the account loses the data and the backups together.
• Restoring over the live database in a panic, which destroys the evidence of what actually went wrong.
• Backing up the database but not the uploaded files, then finding half the records point at objects that no longer exist.
• Never checking that the backup job still runs, or that the file it produced is more than a few kilobytes.

Frequently asked questions

How often should a startup back up its database?

Daily is the baseline, and any product holding work a customer cannot retype deserves point-in-time recovery on top. A useful test: list what your users created in the last 24 hours, then ask how the conversation goes if you have to tell them it is gone. If that conversation would cost you the account, buy the finer granularity.

Is a free-tier database safe to launch on?

Not without your own exports. Supabase does not take automatic backups for free projects and recommends regular dumps kept off-site, which means a scheduled pg_dump into storage you control is the minimum. It costs cents a month and takes an hour to set up.

Someone deleted thousands of rows. Do I have to roll back everything?

No, and usually you should not. Restore the backup into a separate database, copy the missing rows out of it, and insert them back into production. Rolling the whole database back would also discard every legitimate change made since the backup was taken, which often causes more damage than the original mistake.

How long does a restore actually take?

Minutes for a small database and longer as it grows, and the only trustworthy figure is the one you measured yourself. Supabase notes that the project is unavailable while a restore runs, and an RDS point-in-time restore comes up as a new instance whose performance improves in the background as data loads from S3. Both mean your app needs a plan for pointing at a different database.

Do backups need to live somewhere else?

At least one copy should sit outside the account that runs the database. A suspended account, a deleted project or a compromised credential can take the database and its backups in one move, and on Supabase deleting a project removes its backups for good.

Decide this before you need it

Write down your two numbers, check what the plan you are on actually provides, close the gaps that matter most (uploaded files, secrets and one copy held elsewhere), then restore once and time it. That is the entire job, and it is a quiet afternoon now instead of a very loud day later.

If you would rather have senior engineers set this up and hand you the runbook, AlgoSmiths works on fixed-price projects with a working demo every week. Our backend and API engineering work is where backups, restores and the rest of the production setup get built.