Back up Supabase to Google Drive

First, the honest part: Google Drive is not S3-compatible storage — it speaks its own OAuth-based API — and most database backup tools, including our own CLI and hosted service, write only to S3-compatible destinations. So this page is not a pitch. If you want your Supabase backups in the Drive you already have, there are two real paths: a DIY workflow you own (pg_dump + rclone + GitHub Actions, complete commands below), or supabackup, a small hosted service built around exactly this. Both follow, then the reasons most teams eventually move database backups to object storage anyway.

Path A — DIY: pg_dump + rclone + GitHub Actions

rclone is the bridge: an open-source tool that speaks Google Drive’s API on one side and looks like cp on the other. The moving parts are a Google OAuth client, an rclone remote, and a scheduled workflow.

A1 — create your own Google OAuth client

rclone ships a default client ID, but it is shared by every rclone user in the world and throttled accordingly — rclone’s own docs strongly recommend creating your own. In the Google Cloud Console: create a project, enable the Google Drive API, configure the OAuth consent screen, and create an OAuth client ID of type Desktop app. One step people skip and regret: publish the consent screen to production. An app left in Testing mode has its grants expire after about a week — which surfaces later as a scheduled backup that silently stopped authenticating. Publishing does not require Google’s verification process for a personal-use client.

A2 — configure the rclone remote

rclone config
# n) New remote
#   name> gdrive
#   Storage> drive
#   client_id>     <your OAuth client ID — see the note above>
#   client_secret> <its secret>
#   scope> 3       (drive.file — rclone can only touch files it created)
#   service_account_file> (leave blank)
#   Edit advanced config? n
#   Use web browser to automatically authenticate? y
# → browser opens, approve access, rclone saves the token
#   to ~/.config/rclone/rclone.conf

The drive.file scope is the least-privilege choice: rclone can create, read, and delete only the files it created — a leaked token cannot read the rest of your Drive. The browser step is a one-time interactive authentication; the resulting refresh token in ~/.config/rclone/rclone.conf is what the scheduled job will reuse.

A3 — dump and upload

# Session pooler string — Connect button at the top of the Supabase dashboard
export DB_URL="postgresql://postgres.<project-ref>:<password>@aws-0-<region>.pooler.supabase.com:5432/postgres"

pg_dump "$DB_URL" \
  --format=custom \
  --schema=public \
  --file="backup-$(date +%F).dump"

rclone copy "backup-$(date +%F).dump" gdrive:supabase-backups/

The connection string is the Session Pooler URI from the Connect button at the top of the Supabase dashboard (the Direct connection string runs over IPv6 unless the project has the IPv4 add-on, so on an IPv4-only network use the Session Pooler), and your pg_dump major version must be ≥ your project’s Postgres version — Supabase runs PG 15 or 17. --schema=public captures your application schema only; Supabase-managed schemas (auth, storage) are not included, and neither are your Storage files — a database dump never contains them, on any destination.

A4 — schedule it with GitHub Actions

Paste the full contents of your working rclone.conf into a repository secret named RCLONE_CONF, add your pooler string as SUPABASE_DB_URL, and commit this workflow to a private repository (GitHub disables scheduled workflows in public repositories after 60 days without activity):

# .github/workflows/backup-to-drive.yml
name: backup-to-drive

on:
  schedule:
    - cron: "0 3 * * 0" # weekly, Sunday 03:00 UTC
  workflow_dispatch: {} # lets you trigger a backup by hand

permissions:
  contents: read

# Never let two backups overlap.
concurrency:
  group: backup-to-drive
  cancel-in-progress: false

jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      # pg_dump's major version must be >= your Supabase Postgres version.
      # Supabase projects run PG 15 or 17 — postgresql-client-17 covers both.
      - name: Install postgresql-client-17 (PGDG)
        run: |
          sudo install -d /usr/share/postgresql-common/pgdg
          curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc \
            | sudo gpg --dearmor -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.gpg
          echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.gpg] \
          https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" \
            | sudo tee /etc/apt/sources.list.d/pgdg.list
          sudo apt-get update
          sudo apt-get install -y postgresql-client-17

      - name: Install rclone
        run: curl -fsSL https://rclone.org/install.sh | sudo bash

      # RCLONE_CONF secret = the full contents of your working local
      # ~/.config/rclone/rclone.conf ([gdrive] section included). Injected
      # via env so the quotes in the token JSON can't break shell quoting.
      - name: Write rclone config
        env:
          RCLONE_CONF: ${{ secrets.RCLONE_CONF }}
        run: |
          mkdir -p ~/.config/rclone
          printf '%s' "$RCLONE_CONF" > ~/.config/rclone/rclone.conf

      - name: Dump the database
        env:
          DB_URL: ${{ secrets.SUPABASE_DB_URL }}
        run: |
          /usr/lib/postgresql/17/bin/pg_dump "$DB_URL" \
            --format=custom \
            --schema=public \
            --file="backup-$(date +%F).dump"

      - name: Upload to Google Drive
        run: rclone copy "backup-$(date +%F).dump" gdrive:supabase-backups/

      # Drive has no bucket-style lifecycle rules — prune inside the job.
      # rclone moves deletions to Drive's trash by default.
      - name: Prune dumps older than 90 days
        run: rclone delete --min-age 90d gdrive:supabase-backups/

Every run also pulls the whole database out of Supabase, which counts against your plan’s egress allowance — 5 GB/month on the Free plan — so weekly is the sensible frequency for the same reasons the GitHub Actions guide works through in detail.

Path B — hosted: supabackup

If you want Drive backups without owning any of the above, supabackup is the tool actually built for this — Google Drive is not a workaround there, it is the product. Setup is signing in, connecting your Google Drive, and pasting a database connection URI; dumps then land in a folder of the Drive you already pay for. The free plan runs one weekly backup job; Pro is $9/month for three jobs, daily backups, and retention control (keep the latest 7, 14, or 30 backups, or keep everything). It only creates files in its own folder — it cannot read the rest of your Drive.

Its limits are the flip side of the simplicity, and they are the same ones Path A has: database dumps only — no Supabase Storage files — and nothing verifies the dumps restore. Our backup tools roundup compares it alongside the rest of the field. For a side project where “the data exists somewhere outside Supabase” is the goal, it is the shortest path on this page.

Why most teams end up on S3-compatible storage anyway

The pattern we see: Drive is where database backups start, object storage is where they end up. Not because Drive fails, but because four things get harder as backups become infrastructure instead of a folder:

• Machine credentials.A bucket key is a scoped machine credential you can rotate, restrict to one bucket, and hand to CI. A Drive remote is an OAuth grant on a human’s Google account — it expires with Testing-mode apps, and it quietly dies when that person offboards.
• Lifecycle rules and retention. Buckets prune themselves: S3 and R2 lifecycle rules, B2’s hide-then-delete rules. On Drive, retention is another line in your job — and if the job breaks, snapshots accumulate or vanish with nothing watching.
• Verification and the tool ecosystem. Restore tooling, checksummed manifests, and restore testing all assume an S3 API on the other end. This is why the backupdrill engine — the open-source CLI and the hosted service that runs it — writes only to S3-compatible buckets: its restore drills read the snapshot back from the bucket and verify it against a checksummed manifest, which needs object storage semantics Drive does not offer.
• Restore economics. Cloudflare R2 charges zero egress — reading every byte back out, in a real recovery or a drill, is free. Backblaze B2 gives you egress free up to 3x what you store. Those numbers are designed for exactly the read-it-all-back-someday shape of backups.

When you are ready for that move, the destination guides have the complete click-paths: Cloudflare R2 (zero egress), AWS S3 (if your infrastructure already lives there), and Backblaze B2 (cheapest storage) — or the condensed bucket setup docs covering all three.

FAQ