Scaling
Move a service to a larger plan. What happens when you confirm, why storage never shrinks, and what the platform checks before it agrees.
A plan change moves a service to a larger allocation of CPU, memory, storage and I/O. It is never applied automatically: it starts when you confirm it, and it does not wait for your maintenance window.
Plans go up and not down, and the reason is storage.
Change the plan
- Open the service.
- Press Change plan in the header.
- Pick a plan under New plan. Any plan with less storage than the service has is disabled, and the dialog says why.
- Confirm.
The service shows as upgrading while the job runs, and you are emailed when it finishes.
What you can change
| Change | Effect on the service |
|---|---|
| A larger plan | Applied with a restart, because every larger plan has more memory |
| A smaller plan | Not supported. Every smaller plan also has less storage |
| Less storage | Not supported. See below |
| Plan | vCPU | RAM | Storage |
|---|---|---|---|
| Starter | 2 | 4 GiB | 80 GiB |
| Professional | 4 | 8 GiB | 160 GiB |
| Business | 8 | 16 GiB | 320 GiB |
| Performance | 8 | 32 GiB | 500 GiB |
| High Performance | 16 | 64 GiB | 1 TiB |
| Scale | 16 | 128 GiB | 2 TiB |
| Scale 256 | 256 GiB |
Memory and storage rise together from one plan to the next. So moving up always changes memory, and moving down always means less storage.
Storage does not shrink
A plan change that reduces storage is refused with service.storage_below_current. Storage grows
online and it does not come back down: the way to a smaller volume is a dump into a new service on a
smaller plan and a cutover, which is downtime you have to plan for.
The Change plan dialog disables any plan with less storage than the service has, and says why. The platform refuses the same change if it arrives any other way, and the host refuses it a second time.
We document it as a dump and restore rather than hiding it behind a slider that would fail. Choose your storage with that in mind, because over-provisioning is the decision that is expensive to reverse.
What the platform checks first
Capacity is reserved before anything happens. The extra resources are reserved on the host the service already runs on, in the same transaction that accepts your request. The change is refused rather than queued when:
- that host has no room for the growth
- taking it would leave the location's recovery reserve unable to cover the loss of a host
- the location's remaining hosts could not absorb a host failure with the service at its new size
A refusal is an answer about capacity in that location, not a fault in your request, and the same request can succeed later. It names the reason, not the resource that ran out. A plan change never moves a service to another host to make room.
What happens when you confirm
The change runs as a job:
- A backup is taken before anything changes
- The new allocation is applied
- The service is restarted if its memory changed. Connections are dropped and clients reconnect
- A health check runs, and the service is marked healthy
Plan for the reconnection. Any client without retry logic will see the restart as a dropped connection.
What you will see afterwards
The parameter defaults the service reports are derived from its memory allocation, so after the job they are the new plan's:
SELECT name, setting, unit FROM pg_settings
WHERE name IN ('shared_buffers', 'work_mem', 'max_connections');Every plan's starting values are in plan limits.
A plan change, and any storage increase, also puts a restore verification on the service's schedule, because a change to storage or configuration is exactly the kind of thing that can quietly break a backup. See restore verification.
Choosing a size
Size storage with headroom. It is the one dimension you cannot take back.
Measure what you have before you decide:
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database
WHERE NOT datistemplate
ORDER BY pg_database_size(datname) DESC;Pick for the working set you expect rather than the total data size. A database whose hot pages fit in memory behaves very differently from one whose pages do not, and that is a memory decision rather than a storage one.
Troubleshooting
Every larger plan is disabled. The location cannot take the growth right now. Try again later; a refusal is about capacity at that moment.
resource.operation_in_progress. The service already has a job running. related_id in the
error names it, and the Activity tab shows it.
service.not_in_a_state_for_this_operation. A service that is suspended, provisioning or pending
deletion does not accept a plan change.
billing.standing_denied. The organisation's billing state does not currently allow the
operation. See payment failures.