Undo a bad migration or an accidental delete by recovering a database as it was at any moment inside your window. The recovery always lands in a new database, so you can look before you swap.

What you need

Point-in-time recovery (PITR) is part of the dedicated instance, CA$9 a month per project on any paid plan: the project’s own Postgres server process. The other Postgres features that live on it are described in Postgres databases. Backups on every plan are a separate, simpler feature; PITR is for when the moment you want is between two backups.

Turn it on

Choose PITR when you create the instance (canner db instance create --pg 18 --pitr) or switch it on later from the database’s point-in-time recovery panel. From then on Canner archives every change and takes a base backup on a schedule. The restorable range starts when archiving starts: you cannot recover to a moment before it was on. The panel shows the range you can restore and the health of the archive, and you get an alert if archiving starts failing.

Choose the window

The window is how far back you can go: 1 to 35 days, 7 by default. A longer window keeps more archive, and the archive counts toward your organization’s pooled storage (see plans and limits). Anything older than the window is dropped, and dropped for good. Pick the shortest window that covers how long it takes you to notice a mistake, with room to spare.

Pick a moment and restore

Choose a moment inside the window, or “latest”, and Canner recreates the database as it was then. Times are UTC. Nothing existing is touched: the result is a brand-new database. Point-in-time restore in place is not offered, which is the same choice most managed Postgres vendors make.

# 1. Recover the database as it was at a moment (UTC), into a NEW database
canner db pitr-restore orders --to 2026-09-23T14:00:00Z

# ...or the latest archived moment
canner db pitr-restore orders --to latest

Inspect before you swap

When you recover from the dashboard you can choose Inspect first. Canner restores into a temporary inspect database with its own connection string, which is never injected into your app and deletes itself after 24 hours unless you keep or extend it. Look around with any client, or press Compare with live to see which tables are new, missing or different, with row counts. From the CLI, canner db diff <inspect> compares it and canner db inspect <inspect> --keep keeps it as a database. A wrong guess about the moment costs you nothing: recover again at a different time.

Swap it in

If you want the recovered data in place of the original, copy it over. Canner takes a snapshot of the current contents first, so this step can be undone from the snapshot. The connection string your app uses does not change.

# 2. Once you are happy with the restored copy, put it in place of the original.
# --replace snapshots what was there first.
canner db copy orders_restored orders --replace

A copy needs the database it writes over to be replaceable, which is why the flag is explicit. If you would rather keep both, do not swap: point a second app or a one-off script at the restored copy, and pull only the rows you need with a query.

Keep a copy off the server

The archive is compressed and encrypted with AES-256 before it is written, with a key unique to your instance. By default it lives on the same server as the instance, so it protects you from mistakes (a bad migration, an accidental delete), not from losing the server. To survive that as well, add an off-site destination, a bucket you own on any S3-compatible service (canner db offsite add …), then send the archive there:

canner db pitr --offsite <destination>

New WAL and base backups are uploaded within minutes, already encrypted, and the copy follows your window: what the window drops locally is deleted from the bucket too. If files are ever missing on the server, a restore fetches them back from the bucket first. Canner keeps the encryption key, so the bucket alone cannot be read. Shipped files count toward your own bucket, not Canner’s storage pool.

Cost

The dedicated instance: CA$9 a month per project (any paid plan), including 0.5 GB of guaranteed RAM.
Storage: the base backups and WAL count toward your organization’s pooled storage limit. Extra storage is CA$5 a month per 50 GB block.
The off-site copy: whatever your own bucket provider charges.

Limits and things to know

Recovery is always into a new database. There is no in-place point-in-time restore.
The window is 1 to 35 days. You cannot recover to a moment older than the window or from before PITR was turned on.
Turning PITR off permanently deletes the archive.
If the dedicated-instance add-on lapses, the instance is stopped and its data is kept; nothing is deleted automatically.
Canner runs in a single region (Montreal) with no automatic failover. Off-site copies are how you protect against losing the server.

Point-in-time recovery.