canner db | List a project's databases, or init/create one. Starter has one database per project; paid plans can add more. `db init --dedicated [--pitr-days N]` creates the primary on its own dedicated instance with point-in-time recovery; if the project has no dedicated-instance unit, that adds one ($9/month), so it shows the price and needs `--yes`. |
canner db export / import | Download a pg_dump of a database (every plan), or restore one into a database (every plan). |
canner db migrate-in / migrate-out / copy | Stream a database in from (or out to) any public Postgres server, or copy one Canner database into another (copy needs a paid plan). |
canner db rm / pg-version / ops | Delete an additional database, move one to another Postgres version, or check on a running operation. |
canner db external / rotate | Turn external access on/off with an IP allowlist, or rotate a database's password. Every plan. |
canner db backup-policy / backup / backups | Set a database's scheduled-backup interval and retention, take a manual backup, or list/download/restore/delete backups. Starter: at most one backup a day, and restore in place instead of into a new database. |
canner db diff / inspect / backups --verify / alerts | Restore into a temporary inspect database and compare it with the live one, keep or extend it, test-restore a backup, and manage email/webhook alerts. Every plan. |
canner db resources | Show and change the memory budget your app shares with its dedicated instance, and apply it (restarts the instance briefly). Every plan. |
canner db extensions / tuning / restart | Install pgvector, PostGIS, pg_trgm, pg_cron and other extensions on the dedicated instance; pick a workload preset, set timeouts and a maintenance window; restart the instance now. Paid add-on. |
canner db replication | Turn on logical replication (restarts the instance), create publications, watch replication slots and their WAL cap, and give a subscriber a replication login with `canner db roles <name> create <n> --replication`. Paid add-on. |
canner db subscriptions | Follow an external Postgres server live: add a subscription from a connection URL (read from an env var or stdin, never printed) and publication names, then refresh, pause, resume or remove it. Changes are applied with your table owner's rights. Paid add-on. |
canner db metrics / monitoring / insights / logs | Database metrics, and on the dedicated instance: switch on query insights and logs (restarts the instance briefly), list the slowest queries, and read the Postgres log. Every plan. |
canner db roles / offsite | Create read-only or read-write roles with their own connection strings, and manage up to five S3-compatible off-site destinations (add, edit, test, remove) that receive copies of your backups. A read-write role's migration ledger (schema_migrations and similar) stays SELECT-only automatically; `canner db roles <name> write-exclusions <role> <table>` protects any other table the same way, live, without a new connection string. Every plan. |
canner db roles (groups, logins, audit) / inject | Run your own privilege model on the dedicated instance. Create a group (a role nobody logs in as, named by you, that your migrations grant to and attach row-level security policies to; `--adopt` takes over an existing NOLOGIN role of that name) and a login that is a member of your groups and holds nothing else, with no blanket read access. `canner db roles <name> member-of` changes a login's groups live, `canner db inject <name> <login>` picks which login the app receives as DATABASE_URL (the owner by default; it takes effect on the next deploy), and `canner db roles <name> audit` reports what every role can actually do (tables, row-level security, policies) and what looks wrong; `--strict` fails a CI run on any warning. Moving a database or changing its Postgres version is not yet possible while it has groups or logins. Every plan. |
canner db check | A read-only security and performance check of any database, on every plan. It reads the catalog (never your data) and lists: row-level security policies that allow every row, several permissive policies that combine with OR, functions anyone can execute as their owner (SECURITY DEFINER) or without a fixed search_path, views that bypass row-level security, schemas where every role can create objects, tables without a primary key, unindexed foreign keys, duplicate indexes and tables with autovacuum off. On a dedicated instance it also reports the roles: the app connecting as the owner, blanket read access and a writable migration ledger. `--category security|performance` filters, `--strict` exits 1 on any warning for CI, and `--json` prints the whole result. The same check is in the dashboard on each database. |
canner db least-privilege | Run the app as a limited role in one step (dedicated instance). It creates a read-write role (`--label` to name it, default `app`) that can read everything and write data but cannot change the schema, keeps every well-known migration ledger (Prisma, Rails, Django, Flyway and others) read-only for it, even one created by your first migration, and injects it as `DATABASE_URL`. The database owner, which can change the schema, is given to the release command only as `DATABASE_URL_MIGRATE` (never to the build or the running app), so run your migrations there. Safe to run again. Takes effect on the next deploy. `canner db roles audit` shows the result. |
canner db instance upgrade | Upgrade a dedicated instance to a newer Postgres major version in place. `canner db instance upgrade` reports what would stop it; `upgrade run --yes` does it (`--pg 18` names the version). Every database, role, grant, policy and extension carries over and the connection strings do not change, so nothing you built with your own SQL has to be redone. Every database on the instance is offline for a few minutes; if the upgrade fails the instance is left as it was. Point-in-time recovery starts a fresh window afterwards. The previous version is kept for 7 days: `upgrade rollback --yes` goes back (and loses what was written since), `upgrade finish --yes` discards it. |
canner db instance / pitr / pitr-restore / move | Create a dedicated Postgres instance, manage point-in-time recovery, recover a database as of a moment into a new one, copy the recovery archive off-site (`canner db pitr --offsite <destination>`), or move a database onto/off the instance. Paid add-on. |