Point-in-time recovery for Postgres, in Canada.
Undo a bad migration or an accidental delete by recovering a database as it was at any moment inside a window you choose, from 1 to 35 days. The recovery always lands in a new database, so you can look before you swap.
How it works
Scheduled backups are snapshots. If your last backup was at 02:00 and the mistake happened at 14:00, a backup can only give you back 02:00. Point-in-time recovery (PITR) fills the gap. While it is on, Canner takes a base backup on a schedule and archives every change in between, in the write-ahead log (WAL). To recover, you pick a moment, and Canner replays the log from the nearest base backup up to that moment.
- You choose the window: 1 to 35 days, 7 by default. Anything older than the window is dropped for good.
- The restorable range starts when archiving starts. You cannot recover to a moment from before PITR was turned on.
- You pick any moment in the window, or “latest”. Times are UTC.
- Nothing existing is touched. The result is a brand-new database with its own name.
- Inspect first: recover into a temporary database with its own connection string, compare it with the live database (new, missing and changed tables, with row counts), and keep it or let it delete itself after 24 hours.
- To put the recovered data in place, copy it over the original. Canner takes a snapshot of the current contents first, so the step can be undone, and your app’s connection string does not change.
What it costs
PITR is part of the dedicated instance: CA$9 a month per project, on any paid plan. The instance is your project’s own Postgres server process, and it includes 0.5 GB of guaranteed RAM. There is no separate PITR fee on top of the instance.
The archive (base backups and WAL) counts toward your organization’s pooled storage. A longer window keeps more, so pick the shortest window that covers how long it takes you to notice a mistake, with room to spare. More storage is CA$5 a month per 50 GB block. If you send the archive off-site, the copy sits in your own bucket and costs whatever your bucket provider charges, not Canner storage.
Encryption and the off-site archive
The archive is compressed and encrypted with AES-256 (authenticated) before it is written, with a key unique to your instance. Removing the instance removes the key, which makes any leftover copy unreadable. This protects the archive files themselves: a copy of the folder, a snapshot, a shipped copy. It is not disk encryption of the whole server.
By default the archive lives on the same server as the instance. That protects you from mistakes (a bad migration, a deleted table), not from losing the server. To survive that as well, add an off-site destination, a bucket you own on any S3-compatible service, and send the archive there. New WAL and base backups are uploaded within minutes, already encrypted. 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.
Walkthrough: dashboard and CLI
In the dashboard, open the database’s point-in-time recovery panel: it shows the range you can restore and the health of the archive, and you get an alert if archiving starts failing. From the CLI:
# 1. Create a dedicated Postgres 18 instance with PITR on
canner db instance create --pg 18 --pitr
# 2. Recover to a moment (UTC), or to the latest archived moment.
# The result is a new database.
canner db pitr-restore orders --to 2026-09-23T14:00:00Z
canner db pitr-restore orders --to latest
# 3. Once you are happy with the recovered copy, put it in place.
# --replace snapshots what was there first.
canner db copy orders_restored orders --replace
# 4. Optional: send the encrypted archive to a bucket you own
canner db pitr --offsite <destination>How other vendors handle it
PITR is common, but the window, the price and the conditions differ a lot. This is what each vendor’s own pages say. Note that Canner is not unusual in restoring into a new database: RDS, Azure and Heroku do the same.
| Provider | Window | Price or condition |
|---|---|---|
| Canner | 1 to 35 days, restores into a new database | Dedicated instance, CA$9/mo per project; archive counts toward the storage pool |
| Amazon RDS † † | Within the backup retention, 0 to 35 days (7 by default from the console) | Included; a restore creates a new instance |
| Azure Database for PostgreSQL † | Within the backup retention, 7 days by default, up to 35 | Included; continuous log backup (recovery point up to about 5 minutes); a restore always creates a new server |
| Supabase † | 7, 14 or 28 days | Paid add-on on Pro, Team and Enterprise, listed at about $100/month for 7 days, $200 for 14 and $400 for 28; needs at least Small compute |
| Neon † | Restore window of 6 hours on Free, up to 7 days on Launch, up to 30 days on Scale | History is billed at $0.20 per GB-month |
| Crunchy Bridge † | 10 days, to any minute in the window | Included |
| PlanetScale † | Supported through WAL; backups every 12 hours with 2 days of retention included | The page we checked does not give a separate PITR window |
| Heroku Postgres † † | None on Essential; 4 days on Standard; 7 days on Premium, Private and Shield | A rollback creates a new database billed at the plan you choose |
| Render Postgres † | 3 days on a Hobby workspace, 7 days on Pro and above | Paid database plans only |
| DigitalOcean † | The last 7 days | See the vendor’s limits page for conditions |
† Competitor details come from each vendor’s own published pages on the dates shown; prices and plans change, so check the vendor before you decide. Amazon RDS (2026-09-26) · Amazon RDS (2026-09-26) · Azure Database for PostgreSQL (2026-09-26) · Supabase (2026-09-26) · Neon (2026-09-26) · Crunchy Bridge (2026-09-26) · PlanetScale (2026-09-26) · Heroku Postgres (2026-09-26) · Heroku Postgres (2026-09-26) · Render Postgres (2026-09-26) · DigitalOcean (2026-09-26)
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 go back further, or to 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 one region (Montreal) with no automatic failover. Off-site copies are how you protect against losing the server.
Questions
What is the difference between a backup and point-in-time recovery?
A backup is a snapshot at one moment, taken on a schedule. PITR also keeps every change between snapshots, so you can pick almost any moment. Backups are on every plan; PITR needs the dedicated instance.
Can I restore in place?
No. Recovery always creates a new database, so you can inspect it before you decide. To replace the original, copy the recovered database over it: Canner snapshots the current contents first. RDS, Azure and Heroku also restore into a new instance or database.
How far back can I go?
As far as your window, 1 to 35 days, and no further back than when PITR was turned on.
Does the archive count toward my storage?
Yes, the base backups and WAL on the server count toward your organization’s pooled storage. An off-site copy counts toward your own bucket instead.
What happens if the server is lost?
Canner runs in one region on one provider, with no automatic failover. If the archive only exists on the server, it is lost with it. Send a copy to a bucket you own so you can recover from that as well.
Do I need the dedicated instance?
For PITR, yes. It is CA$9 a month per project on any paid plan. Backups, restores (in place on Starter, into a new database on paid plans), “inspect first” and off-site backup copies are on every plan without it. See Postgres on Canner.
Get back to the minute before the mistake.
Start on the free plan, add the dedicated instance to a project when you need it, and set your window.