Supabase PITR pricing: 7, 14 and 28 days
Supabase prices Point-in-Time Recovery as an add-on at $100 per month per 7 days of retention: $100 for 7 days, $200 for 14 days and $400 for 28 days. It is available on Pro, Team and Enterprise plans, and the project must run at least a Small compute add-on. Whether that is money well spent depends on what you expect it to protect, but PITR protects less than most teams assume.
The pricing, precisely
| Retention | Hourly PITR price | PITR add-on | Example Pro total* |
|---|---|---|---|
| 7 days | $0.137/hour | ~$100/month | ~$130/month |
| 14 days | $0.274/hour | ~$200/month | ~$230/month |
| 28 days | $0.55/hour | ~$400/month | ~$430/month |
*The example total assumes one Pro organization ($25/month), one Small compute instance ($15/month), the standard $10 compute credit and no other usage or taxes. The PITR add-on is charged per project. Supabase’s own 7-day example totals about $130/month; the 14- and 28-day totals apply the same documented components.
The numbers come from the Supabase pricing page and the official PITR billing documentation. Two details in the documentation matter for cost planning. First, PITR requires at least a Small compute add-on, so a project on the smallest instance pays for a compute upgrade as well. Second, enabling PITR replaces Daily Backups: Supabase stops taking daily backups because PITR provides finer granularity. Prices and billing rules verified against those sources on 3 August 2026.
Supabase PITR billing questions
Is PITR included in the Supabase Pro plan?
No. Pro, Team and Enterprise projects can enable PITR, but it is a separate add-on for every project. The add-on starts at about $100 per month for 7 days of retention.
Is PITR billed monthly or hourly?
Supabase bills PITR for each hour it is enabled. A partial hour counts as a full hour, so temporarily enabling PITR is prorated but rounded up to the hour.
Does the Spend Cap cover PITR?
No. Supabase explicitly excludes the PITR add-on from the Spend Cap. Enabling it creates billable usage even when the organization’s Spend Cap is on.
What does PITR cost for multiple projects?
The add-on is charged per enabled project. Two projects with 7-day PITR therefore create roughly $200 per month in PITR charges before plan, compute, other usage and taxes.
What you get for the money
PITR archives PostgreSQL write-ahead-log files, by default at two-minute intervals or sooner under load. That allows a restore to any moment inside the retention window with up to seconds of granularity, and a worst-case recovery point of about two minutes. For a bad migration, a destructive UPDATE without a WHERE clause, or an application bug that corrupted rows over several hours, that precision is exactly what you want. A daily backup would lose up to a day of writes; PITR loses minutes.
When PITR is worth $100 or more per month
- Your database changes continuously and losing even an hour of writes is expensive, for example orders, messages or financial records.
- Human operators or migrations touch production regularly, so fine-grained rollback is a realistic recovery scenario, not a theoretical one.
- Your recovery point objective is measured in minutes. Daily backups cannot meet an RPO of minutes; WAL archiving can.
If your data is mostly append-only, low volume, or reconstructible from another system of record, daily backups plus an independent off-platform copy may already meet your objectives, and the add-on budget is better spent elsewhere.
What PITR does not protect
PITR is a database control on the same project. Three boundaries matter when you rely on it as the recovery plan.
- It does not contain Storage file bytes. Supabase documents that database backups include Storage metadata but not the objects themselves. Restoring the database recreates the file catalogue, not the files.
- It restores the database, not the project. Edge Functions, Auth configuration, API keys and project settings live outside the WAL stream and have separate recovery paths.
- It lives inside the project lifecycle. If the project itself is deleted, whether accidentally, maliciously or because of a billing failure, its backups and WAL archive go with it. PITR is not an independent copy.
A practical way to decide
- Write down your RPO. If losing a day of writes is unacceptable, you need PITR or an equivalent WAL-based control.
- Pick the shortest retention that covers how long a silent corruption could plausibly go unnoticed in your team. Seven days is enough when monitoring is good.
- Budget the compute upgrade if you are on the smallest instance.
- Add an independent, off-platform backup for the components PITR does not cover, and restore-test it.
For the broader comparison, read Supabase backups vs PITR. For the components outside the database, see how to back up a Supabase project and the Supabase backup coverage.