Supabase

Supabase's daily backups and PITR are restored inside Supabase. To prove your data is recoverable on its own, keep a logical backup in a bucket you control.

1. Dump on a schedule

Use the session pooler or direct connection string (Project settings → Database), not the transaction pooler:

pg_dump --format=custom --no-owner --schema=public --schema=auth "$SUPABASE_DB_URL" \
  | aws s3 cp - "s3://acme-backups/orders/supabase-$(date -u +%Y-%m-%dT%H-%M).dump"

Run it from a scheduled CI job (see the Neon example) or a small server. Include the schemas your application needs; storage objects (files) are not in the database and need their own backup.

Supabase databases rely on roles and extensions that exist on Supabase. The runner creates missing roles as NOLOGIN placeholders so the restore completes, and lists them in the report; set the extensions_and_version check to warn if extensions differ.

2. Read-only key for Verestore

Create a key limited to listing and reading the prefix: AWS S3 policy, Scaleway or S3-compatible.