Compute plans and parameters

The plans

These are the plans every installation starts with. CPU is the request and the limit of each instance; memory is both the request and the limit, because PostgreSQL sizes its caches against the limit. Storage is the initial size of each instance's data volume, and the WAL volume a separate volume for the write-ahead log.

Plan	CPU	Memory	Storage	WAL volume	Instances	Production tier
nano	0.1–0.5	512 MiB	5 GiB	none	1	No
small	0.25–1	1 GiB	10 GiB	2 GiB	1	No
medium	0.5–2	2 GiB	20 GiB	4 GiB	1	No
standard	1–2	4 GiB	50 GiB	8 GiB	3	Yes
large	2–4	8 GiB	100 GiB	16 GiB	3	Yes
xlarge	4–8	16 GiB	200 GiB	32 GiB	3	Yes
2xlarge	8–12	32 GiB	500 GiB	64 GiB	3	Yes

• nano and small use the installation's standard storage class; the others its premium class.
• A single-instance plan has no replica to fail over to: a failed node means downtime while the instance is started elsewhere. 2xlarge needs nodes with at least 32 GiB of memory free for one pod.
• The production tiers turn on PgBouncer — in transaction mode, with two instances — for a cluster created through the CLI or the API that does not say otherwise. The portal's wizard leaves it to you.

Operators can add plans of their own; they appear in the same list. Which plans a boundary may use can be restricted by its compute plan policy.

Custom

The platform works out which plan a cluster is on by comparing its CPU, memory and instance count with the catalogue. When they match no plan, the cluster is on Custom. You get there by tuning resources individually or by changing the instance count, and leave it by picking a plan — see Tune resources individually.

What a change restarts

Change	Effect
Storage grows	None
CPU, memory, instance count, or a parameter that needs a restart, on a single instance	The database restarts and is briefly unavailable
The same, with more than one instance before or after the change	The instances restart one at a time; connections to the primary drop once
A new major version	Every instance stops while the upgrade runs
Network settings, backups, pooling	No restart reported

The parameters that need a restart are max_connections, superuser_reserved_connections, max_worker_processes, max_wal_senders, max_replication_slots, max_prepared_transactions, max_locks_per_transaction, autovacuum_max_workers, shared_buffers, wal_buffers, huge_pages, shared_preload_libraries, max_parallel_workers, track_commit_timestamp and wal_level.

Derived parameters

A plan tunes PostgreSQL to its memory and connection ceiling. From the plan's memory limit:

• shared_buffers — a quarter of it;
• effective_cache_size — 70 % of it;
• maintenance_work_mem — 5 % of it, at most 2GB;
• work_mem — shared_buffers divided by max_connections, at least 4MB;

and on every plan wal_compression = on, checkpoint_completion_target = 0.9 and random_page_cost = 1.1. synchronous_commit is left at PostgreSQL's default.

Plan	shared_buffers	effective_cache_size	maintenance_work_mem	work_mem	max_connections
nano	128MB	358MB	25MB	4MB	50
small	256MB	716MB	51MB	4MB	100
medium	512MB	1433MB	102MB	4MB	150
standard	1GB	2867MB	204MB	5MB	200
large	2GB	5734MB	409MB	6MB	300
xlarge	4GB	11468MB	819MB	10MB	400
2xlarge	8GB	22937MB	1638MB	16MB	500

The values are written into the cluster when it is created from a plan, and your own values — see Set PostgreSQL parameters — override them one by one. A later plan change does not replace them today: a cluster moved to another plan keeps the parameters it had, max_connections included. Set the ones that should follow the new size yourself.

Parameters you can set

• A name is letters, digits, underscores and dots, starting with a letter or underscore; a value is a single line.
• These parameters are checked before anything is written, and a value PostgreSQL would refuse at start-up is refused with the reason:

Kind	Parameters	Accepted
Whole number	max_connections (1–262143), superuser_reserved_connections, max_worker_processes, max_wal_senders, max_replication_slots, max_prepared_transactions (0–262143), max_parallel_workers, max_parallel_workers_per_gather, max_parallel_maintenance_workers (0–1024), max_locks_per_transaction (at least 10), autovacuum_max_workers (1–262143), default_statistics_target (1–10000), effective_io_concurrency (0–1000)	A whole number in the range
Number	random_page_cost, seq_page_cost, checkpoint_completion_target	Zero or more
Size	shared_buffers, effective_cache_size, work_mem, maintenance_work_mem, autovacuum_work_mem, temp_buffers, wal_buffers, min_wal_size, max_wal_size, wal_keep_size	A number, optionally with B, kB, MB, GB or TB
Duration	statement_timeout, lock_timeout, idle_in_transaction_session_timeout, checkpoint_timeout, autovacuum_naptime, deadlock_timeout, log_min_duration_statement, log_autovacuum_min_duration	-1, or a number, optionally with us, ms, s, min, h or d
On or off	jit, autovacuum, log_connections, log_disconnections, log_lock_waits, track_io_timing	on, off, true, false, yes, no, 1, 0
Choice	huge_pages (on, off, try), log_statement (none, ddl, mod, all), wal_compression (on, off, pglz, lz4, zstd), synchronous_commit (on, off, local, remote_write, remote_apply)	One of the values

Other parameters are passed to PostgreSQL unchecked. The operator itself manages some parameters and may not accept a value for them.