ARCHIVE / 01 — RESTORE-PROVEN POSTGRES BACKUPS

Backups that prove they restore.

Anyone can copy files on a schedule — and find out on the worst day of the quarter that the copies don't restore. OffsiteDB dumps, encrypts, and ships every snapshot to a bucket you own — then restores it into a real Postgres and counts the rows. Your ledger doesn't say “uploaded.” It says proven.

14-day free trial · no card required · works with any Postgres connection string

THE LEDGER — WHAT YOURS WILL LOOK LIKEDRILLED
04:00:11prod-api · supabase⛭ PROVEN · 184 tbl · 9.2M rows · 94s
04:00:09billing-core · neon⛭ PROVEN · 61 tbl · 2.1M rows · 38s
03:00:14prod-api · supabase⛭ PROVEN · 184 tbl · 9.2M rows · 91s
03:00:08analytics-wh · railway⛭ PROVEN · 23 tbl · 41M rows · 188s
02:00:12prod-api · supabase⛭ PROVEN · 184 tbl · 9.1M rows · 95s
02:00:07billing-core · neon⛭ PROVEN · 61 tbl · 2.1M rows · 37s
01:00:15staging-db · render⛭ PROVEN · 48 tbl · 310K rows · 12s
01:00:10prod-api · supabase⛭ PROVEN · 184 tbl · 9.1M rows · 93s
00:00:13analytics-wh · railway⛭ PROVEN · 23 tbl · 40M rows · 184s
00:00:06billing-core · neon⛭ PROVEN · 61 tbl · 2.0M rows · 38s
04:00:11prod-api · supabase⛭ PROVEN · 184 tbl · 9.2M rows · 94s
04:00:09billing-core · neon⛭ PROVEN · 61 tbl · 2.1M rows · 38s
03:00:14prod-api · supabase⛭ PROVEN · 184 tbl · 9.2M rows · 91s
03:00:08analytics-wh · railway⛭ PROVEN · 23 tbl · 41M rows · 188s
02:00:12prod-api · supabase⛭ PROVEN · 184 tbl · 9.1M rows · 95s
02:00:07billing-core · neon⛭ PROVEN · 61 tbl · 2.1M rows · 37s
01:00:15staging-db · render⛭ PROVEN · 48 tbl · 310K rows · 12s
01:00:10prod-api · supabase⛭ PROVEN · 184 tbl · 9.1M rows · 93s
00:00:13analytics-wh · railway⛭ PROVEN · 23 tbl · 40M rows · 184s
00:00:06billing-core · neon⛭ PROVEN · 61 tbl · 2.0M rows · 38s
WORKS WITH  SUPABASE  ·  NEON  ·  RAILWAY  ·  RENDER  ·  FLY.IO  ·  RDS  ·  ANY POSTGRES  ·  WORKS WITH  SUPABASE  ·  NEON  ·  RAILWAY  ·  RENDER  ·  FLY.IO  ·  RDS  ·  ANY POSTGRES  ·  
THE UNCOMFORTABLE PART / 02

“The platform has backups” is not a backup strategy.

Platform snapshots live in the same account, same region, same blast radius as your database. They protect the platform from hardware failure. They do not protect you from:

RISK — A

The Friday-night migration

A bad DROP CASCADE, a botched RLS change, an ORM auto-migration that ate a column. Platform PITR windows are short — and on free tiers, nonexistent.

Walk through the recovery, minute by minute →

RISK — B

The locked account

Billing failure, compromised credentials, a platform suspension. If your only backups live inside the account you just lost, you don't have backups.

RISK — C

The untested restore

The auditor asks: “where are your off-site backups, and what's your tested restore time?” A folder of never-restored dumps is not an answer. A drill log is.

THE RECEIPTS / 03

Every snapshot is restore-drilled. Every month, you get the paper.

This is the part nobody else does. Other tools stop at “file uploaded.” OffsiteDB restores every snapshot into a scratch Postgres cluster, counts tables and rows, measures the clock, and writes it all down.

Restore drills, on real Postgres

initdb → pg_restore → row counts → teardown, for every snapshot. Truncated dumps, bad seals, and corrupt archives are caught the hour they happen — not the day you need them.

The Monthly Restore Drill Report

Backup policy, success rates, drill evidence, and your worst-case observed restore time — auto-generated, emailed, printable. Forward it to the auditor or paste it into the security questionnaire. “Are the backups tested?” becomes a document, not a meeting.

Watchdogs for the silent failures

A deadman alarm fires when backups silently stop running. Table-level diffs catch a shrinking table — a disaster in progress — between snapshots. A bad day gets loud, fast.

RESTORE DRILL REPORT — MAY 2026SAMPLE
prod-api · supabase · hourly · keep 90d ✓ 744 snapshots sealed · 744 drills passed (100%) latest drill: 184 tables · 9.2M rows · 94s worst-case restore (RTO evidence): 112s billing-core · neon · every 6h · keep 90d ✓ 124 snapshots sealed · 124 drills passed (100%) 3 pre-migration checkpoints sealed incidents: none Generated automatically · forwarded to 1 auditor

What restore-tested means → See the full sample report →

PROCEDURE / 04

Three minutes to your first proven snapshot.

STEP 01

Paste a connection string

Any postgres:// URL — a Supabase direct or session-pooler URL, a Neon branch, RDS. A read-only role is all OffsiteDB needs (the security page has the 5-line SQL). We test the connection before saving and encrypt the credential at rest with AES-256-GCM.

$ postgres://readonly:•••@db.xyz.supabase.co:5432/postgres
 connected — postgres @ PostgreSQL 16.4
STEP 02

Point it at your bucket

AWS S3, Cloudflare R2, or any S3-compatible store. Your data lands in infrastructure you control, encrypted before it leaves the worker. We never hold the only copy — by design.

s3://acme-backups/offsitedb/
  2026-06-09T04-00-11_bk_91f3.dump.gz.enc
  2026-06-09T03-00-14_bk_88c1.dump.gz.enc
STEP 03

Watch the drill prove it

Every snapshot is a standard pg_dump custom-format archive — and every one is restored into a scratch cluster before it's marked proven. When the bad day comes, you run one command you've already watched succeed hundreds of times.

$ pg_restore -d $NEW_DATABASE_URL \
      --clean --if-exists prod-api_2026-06-09.dump
 restored 184 tables, 9.2M rows
THE SEATBELT / 05

Never run a migration without a checkpoint again.

One step in CI seals a tagged, restore-drilled snapshot and blocks until it exists — so the migration that goes wrong is the migration you can undo.

# .github/workflows/deploy.yml
- name: Checkpoint before migrating
  uses: offsitedb/checkpoint@v1
  with:
    url: https://offsitedb.com
    api-key: ${{ secrets.OFFSITEDB_API_KEY }}
    database: prod-api
    tag: pre-deploy-${{ github.sha }}
- run: npm run migrate
TARIFF / 06

Cheaper than one hour of data-loss panic.

Every plan ships the full engine: encrypted dumps, your own storage, restore drills, failure alerts, the monthly drill report. Most teams start on Pro — it adds hourly backups and the CI checkpoint API. Plans scale with how much there is to protect.

Hobby
A side project or a single production database.
$9 / month
  • Databases 1
  • Cadence Daily
  • Retention 30 days
  • Restore drills
  • Own S3 / R2 bucket
  • Monthly drill report
Start free trial
Business
Compliance, scale, and priority support.
$79 / month
  • Databases 25
  • Cadence Hourly
  • Retention 1 year
  • Restore drills
  • CI checkpoint API
  • Priority support
Start free trial
STRAIGHT ANSWERS / 07

The questions you should ask any backup vendor.

What happens to my backups if OffsiteDB shuts down?
Nothing — that's the design. Your snapshots live in your own S3/R2 bucket as standard pg_dump archives that restore with stock pg_restore. No OffsiteDB software is required to use them, and in a wind-down customers receive their key material and a documented offline decryption procedure. More on the about page.
What access do you need to my database?
A read-only role. We never need write access for backups, and we test the connection before saving anything. The exact CREATE ROLE snippet is on the security page, along with how the credential is encrypted (AES-256-GCM, key never stored beside the data).
What exactly gets backed up — which schemas?
Everything the connecting role can read: tables, sequences, views, constraints, functions, and extensions, across every schema it has access to. The default role grants the public schema (your app data). If you keep data in other schemas, grant the role access to those too — or use your full postgres connection string to capture everything. On Supabase, public is your data; auth/storage are Supabase-managed and only included if you connect with full credentials. Details on the security page.
My database is behind a firewall / IP allowlist.
Hosted providers like Supabase and Neon accept connections from anywhere by default, so most setups need no changes. If you restrict ingress by IP, email [email protected] and we'll send the current egress IP to allowlist — it's static.
Can I use my Supabase pooler URL?
Use the direct connection or session-mode pooler URL. Transaction-mode poolers (PgBouncer in transaction mode) don't support the session state pg_dump needs — that's a Postgres ecosystem constraint, not an OffsiteDB one. Your Supabase dashboard lists both; either supported one works.
How big can my database be, and what's the load during a dump?
Dumps are streamed — memory stays flat regardless of database size, and multi-GB databases are routine. pg_dump takes a consistent snapshot via MVCC, so it doesn't lock your tables; you'll see read I/O comparable to a large query for the duration. If you run a very large or very busy database, schedule backups off-peak or point us at a read replica.
Who can see my data?
Artifacts are encrypted before they leave the worker, credentials are sealed with AES-256-GCM, and restore drills run in ephemeral scratch instances that are destroyed after row counts are read. We don't browse or mine backup contents — the privacy policy spells out exactly what we collect and the security page covers the rest, including what we are (and honestly aren't) certified for.
LAST CALL / 08

You will need a backup once.

That day, you'll want one that's already proven it restores. Set it up before you need it.

Start free trial →