To further improve availability and fault tolerance, check out Service Replicas
Shared Compute
In a shared model, compute resources are shared amongst users. This is fine if your services mostly run at low to medium load, occasionally burst for brief periods of time, and can tolerate drops in performance. It is important to understand that the availability of CPU time is not guaranteed.Free Plan
Projects on the free tier have a total of 2 shared vCPUs and 1 GiB of RAM spread over services as follows:Service | CPU (MiB) | Memory (GiB) |
---|---|---|
Postgres | 0.5 | 256 |
Hasura | 0.5 | 384 |
Auth | 0.5 | 256 |
Storage | 0.5 | 128 |
Pro Plan
Projects on the pro tier have a total of 2 shared vCPUs and 2 GiB of RAM spread over services as follows:Service | CPU (MiB) | Memory (GiB) |
---|---|---|
Postgres | 0.5 | 512 |
Hasura | 0.5 | 768 |
Auth | 0.5 | 384 |
Storage | 0.5 | 384 |
Dedicated Compute
For production workloads where latency is essential or consistent performance is non-negotiable, we strongly suggest the use of dedicated resources.Compute/Dedicated resources are only available on the Pro plan
nhost/nhost.toml
Disk Performance
Services may require a disk provisioned to store data. For instance, postgres comes with a disk provisioned by default and Nhost Run may too. For these cases we provisioned SSD disks with the following performance:- Baseline: 3000 IOPS
- Baseline: 125Mbps of thoughput
- Every 50GB: +350 IOPS and +15Mbps of throughput
Size | IOPS | Throughput |
---|---|---|
1 | 3000 | 125 |
10 | 3000 | 125 |
49 | 3000 | 125 |
50 | 3350 | 140 |
100 | 3700 | 155 |
300 | 5100 | 215 |