Plan limits
Every published number per plan, and which class each one is: hard ceiling, configuration default or operational limit. The words are not the same.
Every published number per plan, and which of three classes each one belongs to. The class decides the word, and the word decides what you can rely on.
If you are sizing a service, read Resources per plan and Recovery objectives. If you are debugging a refused setting, read Three classes, three words.
Units
Every size on this site is binary. GiB is 2^30 bytes and TiB is 1024 GiB, and where a table or a sentence says GB it means GiB. The plan table, the storage figures and the restore-verification size bands all use the same base, so a database sitting near a band boundary can be worked out from what is published here.
Three classes, three words
| Class | Enforced by | Examples | The word |
|---|---|---|---|
| Hard ceiling | The kernel or the filesystem | Memory, CPU, storage, I/O, max_connections | limit |
| Configuration default | Nothing. You can override per session | work_mem, statement_timeout | default |
| Operational limit | The platform boundary | Database count; role count | limit; guideline for roles |
Using the wrong word here promises enforcement that does not exist, so we are careful with it. You
can set work_mem to 2 GB in a session and we cannot stop you — the cgroup memory ceiling still
holds, so the consequence is confined to your own service.
Resources per plan
| 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 |
All hard ceilings. CPUQuota gives a 2 vCPU service two CPU-seconds per second and no more; there
are no burst credits. MemoryMax is the plan RAM, and page cache for your files is charged against
it. Storage is thick-provisioned, not oversold.
One vCPU is one logical CPU as presented by the host. Where hardware multithreading is enabled, two vCPU are not equivalent to two physical cores under sustained load. The pre-launch benchmark measures per-vCPU throughput on the production host class with multithreading in its production configuration, so plan sizing reflects that rather than a spec sheet.
Starting configuration per plan
These are the values the API returns for a service on each plan. They are written here in
PostgreSQL's own units, exactly as GET /services/{id} and the Configuration tab spell them, so
what you read here is what SHOW work_mem answers on a service nobody has changed. kB, MB and
GB are binary, as everywhere else on this site.
These figures are provisional, pending a benchmark on the production host class. Any change to them appears in the changelog.
| Plan RAM | shared_buffers | work_mem | maintenance_work_mem | max_connections |
|---|---|---|---|---|
| 4 GiB | 1GB | 8MB | 192MB | 100 |
| 8 GiB | 2GB | 12MB | 384MB | 150 |
| 16 GiB | 4GB | 16MB | 512MB | 250 |
| 32 GiB | 8GB | 24MB | 1GB | 400 |
| 64 GiB | 16GB | 32MB | 2GB | 600 |
| 128 GiB | 32GB | 48MB | 2GB | 800 |
| 256 GiB | 64GB | 64MB | 2GB | 1000 |
work_mem and maintenance_work_mem are defaults. A session can raise either one and the cgroup
memory ceiling still holds. shared_buffers is a default too, and changing it takes effect at the
next restart.
The same on every plan
Three defaults do not move with the plan, because none of them is a memory quantity. All three are in milliseconds, all three ship at 0, and 0 means "no cancellation" rather than "immediately".
| Parameter | Default | Minimum | Maximum |
|---|---|---|---|
| statement_timeout | 0 | 0 | 86400000 |
| idle_in_transaction_session_timeout | 0 | 0 | 86400000 |
| lock_timeout | 0 | 0 | 3600000 |
Set by the platform, and not tunable
Two more memory parameters are written into the service's postgresql.conf at creation. They are
not in the tunable set, so there is no API field for them and the dashboard does not offer them.
| Plan RAM | effective_cache_size | autovacuum_max_workers |
|---|---|---|
| 4 GiB | 2560MB | 3 |
| 8 GiB | 5GB | 3 |
| 16 GiB | 10GB | 4 |
| 32 GiB | 20GB | 5 |
| 64 GiB | 40GB | 6 |
| 128 GiB | 80GB | 8 |
| 256 GiB | 160GB | 10 |
What we do not set
The tables above are what a customer can observe and, in the first one, change. The platform also writes the settings that wire a service into its host: where it listens, where its socket lives, how its write-ahead log is archived so the backups work, where its logs go and which events they record. Those are the same on every plan. The first three keep the service reachable and its backups working, and the logging settings decide what reaches the host's journal, so none of them is published here as configuration.
Everything else is whatever the PostgreSQL version ships.
max_connections is a hard ceiling, and it is the binding one
max_connections is set by the platform and enforced by the postmaster, so it is a limit in the
strict sense, and it is the number that stops you. The table above lists it per plan.
Each service unit also has a cap on the number of processes it may run, because PostgreSQL forks a
backend per connection. That cap is derived from the same plan profile that sets max_connections,
with headroom above it for PostgreSQL's background workers, so it is not reached before the
connection limit is. You get sorry, too many clients already, which names the real cause.
Application traffic goes through the pooled endpoint so that a few hundred clients do not become a
few hundred backends. Size your own connection pool against your plan's max_connections. See
pooled vs direct.
I/O allocation
Each plan's I/O allocation is a pair: an IOPS ceiling and a throughput ceiling. Both are set from a benchmark on the production host class and published as measured values, never as estimates.
I/O is capped per service with hard caps rather than proportional weights, because a proportional share that varies with your neighbours is not predictable, and predictability is the product.
PostgreSQL versions
16, 17 and 18. New services default to 18.
Backup retention
7, 30, 90 or 365 days.
Recovery objectives
- Recovery point objective: 5 minutes or better under normal operation. Suspended for as long as we have told you an archive failure is in progress.
- Process crash or reboot with storage intact: recovered automatically, by restarting PostgreSQL and replaying the write-ahead log still on local storage.
- Host loss: recovered by rebuilding the service from backup on another host in the same location.
Recovery times are published by database size band once recovery drills on production hardware have produced them, and the time an automatic restart takes once it has been measured.
Availability
99.5% monthly, measured per service, single-node, excluding announced maintenance. The figure is a provisional target, reviewed against measured availability. The arithmetic is in the Service Level Agreement.
Availability is measured by external probes on at least two networks. For any period no external measurement record covers, the SLA says how a credit claim is assessed.
Troubleshooting
SHOW work_mem disagrees with the table. Something changed it on your connection or on the
role. Parameters has the query that says which, and what each answer
means.
A change to a value is refused as not settable. It is a hard ceiling rather than a default. The three classes above are the distinction, and only the second class can be changed.
sorry, too many clients already. You have reached max_connections, which is the binding
limit on this page.
A size here looks smaller than you expected. Every size on this site is binary. 80 GiB is not 80 GB, and the difference is about seven percent.