Resize

shell

zb instances resize pg-prod --size m4                                   # compute
zb api PATCH /v1/orgs/{org}/instances/pg-prod -d '{"storage_gb": 60}'   # storage, grow only
zb api GET /v1/orgs/{org}/instances/pg-prod/options                     # what it can change to now, and why not

In the portal: Instance → Settings → Size and storage. It lists the sizes your plan offers, says why a size is not available (a size too small for the data, above the plan maximum), shows the new monthly price, and asks before anything changes. Progress and the outcome appear under Recent changes.

What happens

1. A size change takes a backup first.
2. Operator-backed engines (PostgreSQL, MySQL): a rolling restart. With HA (read replicas, Solo and above) the primary fails over and the interruption is a few seconds; single-node instances are unavailable for the pod restart, typically 20 to 60 seconds.
3. Simple engines (Valkey, libSQL, FerretDB): the StatefulSet pod is recreated; 10 to 30 seconds.
4. Storage grows with no restart.

While the change runs the instance reports modifying; it is back to ready when the engine has restarted.

Rules

• Any size to any size within the plan’s max_size (see limits); f0 is free-tier only. A size must hold the instance’s provisioned storage.
• A size the instance’s node cannot schedule is refused before anything changes, with the room the node has left.
• Storage grows to any whole number of GB up to the size’s ceiling, the plan’s per-instance limit and your storage quota (GET …/options names the limit that applies), and never shrinks; to shrink, restore into a smaller instance.
• One change of each kind at a time: a second resize while one runs is refused (409).
• Billing switches to the new size at the minute the change completes; usage is derived from state transitions, not sampled.
• Approvals (Team and Enterprise): sizes above a team’s threshold create an approval request instead of resizing; see Teams and approvals.