Backups: what we keep, and what you should keep

Two different fears get called "backups", and they need two different answers. The service could lose my data — that one is ours to handle, and this page says how. I could lose access to the service — that one is yours, it costs one click, and no backup of ours substitutes for it.

What we keep

Every night, a complete copy of the database — every tenant's structure and records — is taken with Postgres's own dump tooling, compressed, and shipped off-site to Cloudflare R2, separate storage from the box that runs Tabla. Copies are kept for 30 days; each night's run prunes anything older.

Two details we hold ourselves to:

• A backup that can't prove itself doesn't ship. Each dump is checked for Postgres's own end-of-dump marker before upload — a truncated copy fails loudly instead of quietly replacing good ones for thirty nights.
• Restores are rehearsed, not assumed. The restore path has been run for real — a genuine backup taken, shipped, pulled back down and restored into an empty database, with every row confirmed to match. A backup you have never restored is a hope, not a backup.

Attachment files live in object storage (Cloudflare R2) in the first place, a separate durability story from the database dumps — and the backup run covers the file bytes as well, so a restore doesn't produce records pointing at missing files. The wider picture of where everything physically lives is where your data lives.

What our backups are not

They are disaster recovery for the whole service — the box dying, a bad migration, the kind of day that makes the news. They are not a per-table undo. There is no button that lifts one deleted table for one customer out of a whole-system nightly copy, and the delete dialogs are worded accordingly: what's recoverable and what isn't is decided by the product's own rules — a 7-day trash for records and for tables, finality for fields and databases — not by the existence of our nightlies.

They also cannot protect you from the failure mode where we are the problem: the company folds, the service degrades, you want out. A backup held by the party you're trying to leave is not leverage.

What you should keep

Export your database. One click, one zip, synchronously: the full structure, every record, every attachment byte, in open formats — CSV, JSON, your files as files. It needs no Tabla to open and no permission to use. The same export is one curl away, so a weekly cron job can keep a copy on a disk you control:

curl -L -o tabla-backup.zip \
  -H "Authorization: Bearer key_xxxx.your-secret" \
  https://tabladb.com/api/databases/db_rci9p7iggin5/export

The honest division of labor, in one line each:

• Our nightlies protect everyone against our disaster.
• Your export protects you against us.

We built the export to be complete precisely so the second line would be true — the argument, and what it commits us to, is spelled out on /your-data.

The questions people ask

Can you restore my table to last Tuesday? Not from a backup — that's not a product feature, and honesty means not implying otherwise. What the product does have is a 7-day trash, for records and for whole tables, both of which you restore yourself. A field or a database you deleted is gone. Export before big changes.

How current is the newest backup? Backups run nightly, so the newest copy is at most a day old. The live database is the live database — backups are for disasters, not for reading yesterday.

Do I need to do anything for backups to happen? No. They cover every database automatically. The export habit is the part only you can do.