Compute and Disk

Compute

Every project on the Zuvo Platform comes with its own dedicated Postgres instance.

The following table describes the base instances, Nano (free plan) and Micro (paid plans), with additional compute instance sizes available if you need extra performance when scaling up.

Compute sizes can be changed by first selecting your project in the dashboard here and the upgrade process will incur downtime.

We charge hourly for additional compute based on your usage. Read more about usage-based billing for compute.

Dedicated vs shared CPU

All Postgres databases on Zuvo run in isolated environments. Compute instances Nano to 2XL compute size have CPUs which can burst to higher performance levels for short periods of time. Instances bigger than Large have predictable performance levels and do not exhibit the same burst behavior.

Compute upgrades [#upgrades]

When considering compute upgrades, assess whether your bottlenecks are hardware-constrained or software-constrained. For example, you may want to look into optimizing the number of connections or examining query performance. When you're happy with your Postgres instance's performance, then you can focus on additional compute resources. For example, you can load test your application in staging to understand your compute requirements. You can also start out on a smaller tier, create a report in the Dashboard to monitor your CPU utilization, and upgrade as needed.

Disk

Zuvo databases are backed by high performance SSD disks. The effective performance depends on a combination of all the following factors:

• Compute size
• Provisioned Disk Throughput
• Provisioned Disk IOPS: Input/Output Operations per Second, which measures the number of read and write operations.
• Disk type: io2 or gp3
• Disk size

The following sections explain how these attributes affect disk performance.

Compute size

The compute size of your project affects the effective disk throughput and IOPS. The table below shows both the baseline (sustained) limits and the burst (maximum) limits for each instance size. For instance, an 8XL compute instance has a throughput of 1,188 MB/s and IOPS of 40,000.

Smaller compute instances like Nano, Micro, Small, and Medium can burst above baseline for short periods of time. Once burst capacity is exhausted, performance returns to baseline. If you need consistent disk performance, consider upgrading your compute size.

Larger compute instances (4XL and above) are designed for sustained, high performance with specific IOPS and throughput limits which you can configure. If you hit your IOPS or throughput limit, throttling will occur.

Choosing the right compute instance for consistent disk performance

If you need consistent disk performance, choose the 4XL or larger compute instance. If you're unsure of how much throughput or IOPS your application requires, you can load test your project and inspect these metrics in the Dashboard. If the Disk IO % consumed stat is more than 1%, it indicates that your workload has exceeded the baseline IO throughput during the day. If this metric goes to 100%, the workload has used up all available disk IO budget. Projects that use any disk IO budget are good candidates for upgrading to a larger compute instance with higher throughput.

Provisioned disk throughput and IOPS

The default disk type is gp3, which comes with a baseline throughput of 125 MB/s and a default IOPS of 3,000. You can provision additional IOPS and throughput from the Infrastructure settings page, but keep in mind that the effective IOPS and throughput will be limited by the compute instance size. This requires Large compute size or above.

Disk types

When selecting your disk, it's essential to focus on the performance needs of your workload. Here's a comparison of our available disk types:

For general, day-to-day operations, gp3 should be more than enough. If you need high throughput and IOPS for critical systems, io2 will provide the performance required.

Disk size

• General Purpose (gp3) disks come with a baseline of 3,000 IOPS and 125 MB/s. You can provision additional 500 IOPS for every GB of disk size and additional 0.25 MB/s throughput per provisioned IOPS.
• High Performance (io2) disks can be provisioned with 1,000 IOPS per GB of disk size.

Limits and constraints

Postgres replication slots, WAL senders, and connections

Replication Slots and WAL Senders are used to enable Postgres Replication. Each compute instance also has limits on the maximum number of database connections and connection pooler clients it can handle.

The maximum number of replication slots, WAL senders, database connections, and pooler clients depends on your compute instance size, as follows:

Constraints

• You can modify disk attributes up to four times within a rolling 24-hour window. A new modification can be initiated as soon as the previous one completes. If you reach this limit, you will encounter throttling and must wait for the rolling 24-hour window to permit further adjustments.
• You can increase disk size but cannot decrease it.