---
title: "Supabase backups: PITR and pg_dump"
slug: "supabase-backups"
category: "ops"
tags: ["ops", "supabase", "backups", "postgres", "pitr", "disaster-recovery"]
status: "stable"
last_updated: 2026-09-27
summary: "How to back up a Supabase project: enable point-in-time recovery, restore in place or to a new project, and keep nightly pg_dump copies in a separate account."
related: ["[[ops/disaster-recovery]]", "[[backend/supabase]]", "[[ops/postgres-prod]]", "[[backend/postgres]]", "[[ops/hostinger-vps-backups]]"]
---

## Overview

Supabase includes automatic daily backups on paid plans, but those backups live inside Supabase's infrastructure and restore on Supabase's terms. Pair point-in-time recovery (PITR) for a short recovery point with nightly logical `pg_dump` exports that you store yourself. This page covers both for Supabase specifically. Setting RPO and RTO targets, backing up secrets, and running restore drills are covered in [[ops/disaster-recovery]]; generic Postgres backup and WAL archiving are in [[ops/postgres-prod]].

## Enable PITR when the RPO is shorter than a day

Supabase PITR streams WAL segments to object storage, allowing restore to any second within the retention window (roughly a two-minute RPO in the worst case). It is an add-on on Pro, Team, and Enterprise plans, and the project must also run at least a Small compute add-on. Enable it under Dashboard > Settings > Add-ons. Pricing scales with the retention window, starting at $100/month for 7 days (checked September 2026) and rising for 14- and 28-day windows; confirm current rates on the [Supabase pricing page](https://supabase.com/pricing). To restore in place, go to Dashboard > Project > Settings > Database > Backups > Point-in-Time, select the target timestamp, and confirm. The project is inaccessible during the restore; plan for downtime proportional to database size. Supabase also offers a "Restore to a New Project" option that creates a separate copy without downtime on the source project; prefer it when you need to inspect or recover a subset of data rather than roll back everything. ([Supabase PITR docs](https://supabase.com/docs/guides/platform/backups))

## Export nightly logical dumps to storage you control

A logical `pg_dump` complements PITR by producing portable snapshots you can move to a separate account. Run a nightly dump and compress the output:

```bash
pg_dump "$DATABASE_URL" \
  --format=custom \
  --compress=9 \
  --file="backup-$(date +%Y%m%d).dump"
```

Retain daily dumps for 30 days, weekly dumps for 90 days. Store them in a bucket under a separate cloud account; see [[ops/hostinger-vps-backups]] for the restic-to-B2 pattern that applies equally here.

Test that a dump restores with `pg_restore` into a scratch database; a dump file that has never been restored is unverified. See [[backend/postgres]] for `pg_restore` flags.

## Related

- [[ops/disaster-recovery]]: RPO/RTO, offsite storage, alerting, and restore drills
- [[backend/supabase]]
- [[ops/postgres-prod]]
- [[backend/postgres]]
- [[ops/hostinger-vps-backups]]