Backups, and restoring one before you need to

What the free tier actually keeps

Hosted databases advertise backups, and the word covers very different things. Neon’s free plan keeps a history you can restore to for a short window: a day at the time of writing, longer on paid plans. Supabase’s free plan has no automatic backups at all; daily backups start on the paid tier. Turso and D1 have their own windows. Read the current page for your provider, because these change, and write the number down somewhere you will see it.

The number is the point. A window of 24 hours means that a deletion noticed 25 hours later is permanent. Deletions are noticed late (a user writes in a week after their data vanished) and an app whose only backup is the provider’s window is protected against the mistakes you catch quickly and nothing else.

A dump you own

pg_dump writes the whole database to a file:

pg_dump "$DATABASE_URL" --format=custom --file=backup-2026-09-06.dump

That file is yours. It can sit in a bucket in object storage (the same R2 or B2 account as the uploads) or on a disk you control. A small app’s database is a few megabytes; the storage cost is nothing.

Automate it. A scheduled job on the host, a GitHub Action on a cron schedule, or a one-line script on any machine that is on daily. Once a day, kept for thirty days, is the shape that catches the week-late report. The script is twenty lines and the agent will write it correctly if you tell it where the dump should go.

For SQLite, the database is a file, and the backup is a copy of the file, but copy it with the .backup command or the VACUUM INTO statement rather than cp, because a copy taken mid-write can be corrupt.

Restore it once, now

A backup that has never been restored is not known to work. The dump might be of the wrong database, missing a schema, taken with a version of the tool the restore does not accept, or empty because the connection string in the script pointed at development. All of these have happened to people who had a green tick on their backup job.

So, once, and again after any change to the script:

createdb restore_test
pg_restore --dbname=restore_test backup-2026-09-06.dump
psql restore_test -c "SELECT count(*) FROM bookings;"

Compare the count with production. Open the app against the restored database if you can. Then drop it. Now you know two things: that the backup is real, and how long a restore takes, which is the number you will want at the worst possible moment.

What the database backup does not contain

Uploaded files live in the bucket, not the database, so the dump does not have them. Bucket providers offer versioning (keeping old copies of overwritten or deleted objects) which is the equivalent and is usually a checkbox.

Environment variables live on the host. Keep a copy of the names, and of the values, somewhere safe: a password manager entry is the usual answer. Losing the host account with no record of the variables means reconstructing every key from every provider.

And the host’s own configuration (domains, build settings, the production branch) is nowhere but the host. A screenshot of the settings page is a crude and effective backup.

The scenario this is for

The data block keeps returning to one event: an agent, or you, running a destructive command against production. A reset, a migration that dropped a column, a DELETE with no WHERE. The rules file, the separate credentials and the forbidden list make it rare. The backup is what makes it survivable, and it is only that if the restore has been rehearsed.

Set a reminder for the first of each month: restore last night’s dump into a scratch database and count one table. Five minutes, and the difference between a bad morning and the end of the project.