Supabase point-in-time recovery (PITR), explained

PITR is a Supabase add-on that restores your database to any second within a retention window, instead of to last night’s backup. It works by continuously archiving write-ahead log files on top of physical backups. It costs $100/month per project for a 7-day window and replaces daily backups rather than adding to them.

Below: how it actually works, the prerequisite that makes the real monthly bill closer to $130, the three things it does not cover, and how to turn it off.

How PITR works

Postgres writes changes to a write-ahead log before applying them to the data files, giving an ordered record of what happened to the database. One exception matters if you use it: UNLOGGED tables skip the WAL by design, so their contents are outside PITR entirely — as they are outside crash recovery. PITR is the practice of keeping those log files alongside a base backup: to reach any moment in time, restore the base backup and replay the log up to exactly that point. Supabase implements this with WAL-G, an open-source archival tool, combining physical backups with WAL archiving.

The archiving cadence is the part worth internalizing. Supabase backs up WAL files at two-minute intervals by default, more often when a file crosses a size threshold or transaction volume is high, and not at all while the database is idle. Treat that as a nominal cadence, not a contractual RPO — the authority on what you can actually recover to is the latest recovery point the dashboard shows you, which is worth looking at before you write a number into a recovery plan. As a planning figure: up to about two minutes of recent writes may not be archived yet when a failure hits. On an idle database the newest restore point can be considerably older than two minutes and nothing is wrong — there were no writes to archive, so that stale-looking point still represents the current state.

For a table dropped at 14:32:06 none of this matters; you are targeting a moment in the past and the log for it was archived long ago. It matters for hardware failure, where the loss is whatever had not been archived at the instant things stopped.

How to enable it

PITR is a per-project add-on on the Pro, Team, and Enterprise plans, switched on under Project Settings → Add-ons. Two prerequisites catch people out:

At least a Small compute instance. Supabase requires it for PITR to function smoothly. If your project is on Micro — which is what a paid plan’s included compute credits cover — enabling PITR means a compute upgrade too, and that upgrade is billed separately from the add-on.

Physical backups become the mechanism. PITR runs on physical backups, and physical backups cannot be downloaded. If your project was on the older logical backup process with a download button in the dashboard, enabling PITR takes that button away.

What PITR actually costs

The add-on is priced by retention window and billed hourly in arrears, per project. Note the rounding: if PITR is active for part of an hour, that whole hour is charged — enabling it briefly to test is not free.

Those numbers are the add-on in isolation, which is not what arrives on the invoice. Add the plan and the compute requirement and one Pro project with 7-day PITR looks like this: $25 for Pro, plus a Small compute instance at about $15/month against the $10 in compute credits a paid plan includes, plus $100 for the add-on — roughly $130/month for one project. Prices as of August 2026.

Two more billing details worth knowing before you enable it on a whim. It is priced per project, so three projects that each matter is three times the number. And the PITR add-on is explicitly not covered by the Spend Cap — the safety net that stops other usage from running away does not apply here.

What it covers, and what it does not

The Storage row is the expensive one, and the damage is asymmetric rather than total. The object store is not rolled back with the database, so restoring to 14:00 yesterday leaves files that existed then and still exist working normally. What breaks is everything on either side of the line: files deleted since 14:00 come back as storage.objects rows pointing at objects that are gone, and files uploaded since 14:00 stay in the bucket as orphans with no row describing them — invisible to your app, still on your storage bill. Restore into a new project instead and the problem is simpler and worse: no files travel at all. The Storage backup guide covers the separate copy those files need. Paying $100/month does not change this.

Two more things to plan for. Enabling PITR stops daily backups — the docs are explicit that running both is considered unnecessary — so PITR is not an extra layer, it is a replacement. And a restore takes the project offline: it is inaccessible while the restore runs, for a duration that scales with database size. PITR shortens how much data you lose; it does not make recovery instant or invisible.

Running one is short: Database → Backups, the Point in Time tab, pick the timestamp, confirm. Two things to decide before you click. First, the timestamp is entered in a timezone the dashboard shows you — read it rather than assuming UTC, because being off by a few hours reproduces the incident you are recovering from. Second, an in-place restore overwrites the current database: whatever was written between your target time and now is discarded, including anything correct that landed after the mistake. Where that trade is unacceptable, use Restore to a new project from the PITR timestamp instead, then move only the rows you need across. It leaves production up while you work.

How to remove or disable PITR

Same place you enabled it: Project Settings → Add-ons, remove the Point-in-Time Recovery add-on. Because billing is hourly, charges stop from the time of removal rather than at the end of a cycle — a project that ran PITR for a weekend is billed for a weekend.

The part that surprises people: turning PITR off does not give you the old downloadable backups back. Supabase’s docs state that when PITR is disabled, new backups are still taken as physical backups only — and physical backups are not available for direct download. If your reason for disabling PITR was to get files you can keep, that plan does not work; you need your own logical dump, which the .sql export guide covers — and you can run that dump any time, before or after removal; nothing about disabling PITR takes pg_dump away. What removal does take away is the past: the moment the add-on goes, so does the ability to recover any earlier point in the window. So if there is a specific moment you might want — the state before a migration, last Tuesday’s data — restore or clone to it while PITR is still on. What remains afterwards is whatever restore points the backups page lists — the plan’s physical backups still exist and still restore; you just lose the ability to land between them.

When PITR is the right purchase

It is, straightforwardly, the best recovery granularity available for a Supabase database. If losing a day of writes would be a serious business problem — a transactional app, anything with payments, anything where users create content continuously — the granularity is worth real money and $100/month is not an unreasonable price for it. Nothing else on the market restores a Supabase project to 14:32:06.

Where it fits poorly: it is per-project, so a portfolio of small projects multiplies badly. It covers the database only. It leaves no copy outside Supabase, which is the exact scenario a disaster recovery plan is supposed to survive — an account problem, a billing lapse, a deleted project, and PITR’s window disappears with everything else. And it tells you nothing about whether a restore works until the day you run one.

Those are complementary weaknesses rather than competing ones, which is why running PITR alongside an external backup is a coherent position rather than a redundant one — PITR for granularity, a snapshot in your own bucket for independence. The side-by-side comparison with BackupDrill goes through the cost and coverage tradeoff in detail, including where PITR wins outright.

FAQ