ReviveDB
Blog
July 18, 2026

Supabase PITR cost: pricing, when it is worth it, and what it still misses

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—and PITR protects less than most teams assume.

The Supabase recovery boundary

PITR pricing only makes sense next to what it protects: the database on the same project. The rest of the recovery boundary—Auth configuration, Storage bytes, Edge Functions and project settings—needs its own independent, verified copy regardless of which PITR tier you choose.

The pricing, precisely

  • 7 days of PITR retention: $100/month (about $0.137/hour).
  • 14 days of PITR retention: $200/month (about $0.274/hour).
  • 28 days of PITR retention: $400/month (about $0.55/hour).

The numbers come from the Supabase pricing page and the database backups documentation. Two details in that 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.

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—orders, messages, 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—accidentally, maliciously, or through a billing failure—its backups and WAL archive go with it. PITR is not an independent copy.

A practical way to decide

  1. Write down your RPO. If losing a day of writes is unacceptable, you need PITR or an equivalent WAL-based control.
  2. Pick the shortest retention that covers how long a silent corruption could plausibly go unnoticed in your team—7 days is enough when monitoring is good.
  3. Budget the compute upgrade if you are on the smallest instance.
  4. 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 complete Supabase project and the complete Supabase backup workflow.

Why ReviveDB is deliberately Supabase-specific

General backup platforms are designed to copy many kinds of databases, servers and files. ReviveDB goes narrower and deeper: it treats the Supabase database, Auth, Storage, Edge Functions and recoverable configuration as one provider-aware recovery point. See the complete Supabase backup and recovery workflow.