← All postsData

Canner Postgres update: point-in-time recovery, extensions, replication and live migration

Managed Postgres has been on every Canner plan for a while: an isolated database and role per project, scheduled and encrypted backups, restore into a new database, copies to your own S3-compatible bucket. Some workloads want more than that from a database, and until now the answer was “use someone else’s.” This update adds the missing pieces, all of them on the dedicated instance, an add-on at CA$9 a month per project on any paid plan.

What the dedicated instance is

It is the project’s own Postgres server process, with its own data directory and its own memory cgroup, and 0.5 GB of guaranteed RAM included. You pick Postgres 17 or 18 when you create it. That separation is what makes the features below safe to hand to a customer: an extension, a logical replication slot or a restart only ever affects one customer’s server.

Point-in-time recovery

Canner archives every change and takes base backups on a schedule. You choose a window from 1 to 35 days (7 by default), pick a moment inside it, and Canner recreates the database as it was then:

canner db pitr-restore <name> --to 2026-09-23T14:00:00Z

The result is always a new database. We do not restore in place, which is the same choice most vendors make, and it means a wrong guess about the moment costs you nothing. You can restore into an inspect database first and compare it with the live one, then swap it in with canner db copy … --replace, which snapshots the current contents before replacing them. The archive is compressed and encrypted with AES-256 before it is written, and you can send a second encrypted copy to a bucket you own so it survives the loss of the server. The archive counts toward your pooled storage.

Extensions

The catalog has 14 extensions, including pgvector, PostGIS, pg_trgm, pg_cron and hstore, installed with canner db extensions <name> install vector. The list is fixed on purpose. Extensions that reach other servers or read the host’s files (postgres_fdw, dblink, file_fdw) are not offered, because on a shared machine they are a way out of your instance. If you need cross-server queries from inside the database, that is a real limitation, and another provider may suit you better.

Monitoring and tuning

Turn on query insights and you get your slowest and busiest queries and a searchable log, kept seven days. Pick a workload preset (balanced, read-heavy, write-heavy, analytics), set statement, idle-in-transaction and lock timeouts, and choose a two-hour maintenance window for planned restarts.

Replication out, and following a server in

Logical replication can now stream a database’s changes to your own subscribers, through a replication login limited to that one database. In the other direction, an inbound subscription lets a database follow an external Postgres server live, so you can move without downtime: rows are copied first, then changes stream in, and you cut over when the two agree. Up to five per database. The source has to be at a public address. We wrote up how both directions are locked down in Running logical replication safely, and there is a step-by-step migration guide.

What this is not

Being plain about it matters more than the feature list.

  • No high availability. Canner is one region (Montreal) on one provider. There is no multi-zone setup and no automatic failover. A server failure means restoring from backups or the recovery archive, and the off-site copies exist for exactly that day.
  • No read replicas, no branching, no autoscaling to zero, and no database-only product without the app platform.
  • No in-place point-in-time restore. New database, then swap.

If your requirement is a contractual uptime SLA across zones, or instant branches per pull request, a hyperscaler or a branching-first vendor is the better fit today, and we would rather you know that before you move.

Memory and cost

Your app and its dedicated Postgres share one memory budget. Dedicated RAM (CA$19 per GB per month) is guaranteed and never oversold, and is the safer choice for Postgres and AI workloads; App RAM (CA$4 per GB per month) is pooled and slows down, rather than cuts off, when the server is busy. Plans & limits shows how to choose. Storage is one pool per organization covering databases, backups and the recovery archive: 5 GB on Starter, 25 GB on Live, 100 GB on Studio, with 50 GB blocks at CA$5 a month.

Why it lives here

Canner is Canadian-owned with no US affiliate, and hosted only in Montreal, so it is not subject to the US CLOUD Act. Your data, the recovery archive and the optional off-site copies stay in the places you choose. The full walkthrough is in the Postgres docs, and the guide to point-in-time recovery starts from turning it on.

About the author

Colin Shand is the founder of Canner, a Canadian deployment platform operated from Quebec. He writes about sovereign infrastructure, the Canadian startup ecosystem, and building independently.

Try Canner.

Drop a project, get a live URL on Canadian infrastructure in about 30 seconds. Free tier available.