Service operations - Autoscaling

Timescale Cloud allows you to resize compute (CPU/RAM) and storage independently at any time. This is useful when you need to do something like increasing your storage capacity, but not your compute size. You can resize compute and storage in the Timescale Cloud console for any service, including members of multi-node clusters.

Storage changes are applied with no downtime, and the new storage capacity is usually available for use within a few seconds.

• Storage can only be increased in size. You cannot decrease the amount of storage capacity your service has available.
• Storage size changes can only be made once every six hours.
• Storage can range in size from 10 GB to 16 TB, and can be changed in various increments.

You can increase or decrease the compute size of your service at any time, with a short downtime.

• There is momentary downtime while the new compute settings are applied. In most cases, this downtime is less than 30 seconds.
• Because compute changes require an interruption to your service, plan accordingly so that the settings are applied during an appropriate service window.

To modify the compute or storage of your service, select the service that you want to modify, and navigate to the Operations tab. Go to the Resources section to see the current resource settings for the service.

When you change compute or storage settings, the current and new hourly charges are displayed immediately so that you can verify how the changes impact your costs.

You can use the Timescale Cloud console to change how much CPU and memory resources your service has available, as well as change the disk size for your service. You can adjust this manually as required, or for disk size you can use autoscaling.

Change resource allocations manually

You can manually change both storage and compute resources.

Storage resources

When you change the disk size, the changes are applied with no downtime. The new size generally becomes available within a few seconds. You can only increase your disk size, not decrease it, up to a maximum of 16 TB.

Though your new storage is available within seconds, it needs to be optimized behind the scenes. Optimization takes anywhere from 6 to 24 hours for each terabyte of data. Allow enough time for optimization to finish before scaling your service again. You must wait at least 6 hours, even if your service is smaller than 1 TB.

Compute resources

You can change the CPU and memory allocation for your service at any time, with minimal downtime, usually less than thirty seconds. The new resources become available as soon as the service restarts. You can change the CPU and memory allocation up or down, as frequently as required.

Configure autoscaling for disk size

Disk size autoscaling is enabled by default on most services. When you consume 85% or more of your existing disk space, disk size is automatically increased to the next size available, up to a configurable limit.

Autoscaling can only increase disk size, not decrease it. You can have a disk up to 16 TB in size.

Autoscaling can change the disk size once every 6 hours. When the increase is requested, the new limit is applied, and then the used space is optimized. The optimization process does not require downtime, and in most cases it happens very quickly. However, if you have a lot of existing data, optimization can take longer. You should expect 6 to 24 hours of optimization time for every terabyte of data. For more information, see the Amazon Elastic Block Store documentation.

If you have a Timescale Cloud multi-node cluster, you can also use autoscaling. We recommend that you define different scale limits for the access node and data nodes, not just because they have different workloads, but also because access nodes are less demanding for storage than data nodes. Data nodes have a single scaling threshold that applies across all the data nodes.

Limitations of autoscaling

Under very heavy data ingest loads, your data might grow faster than your new storage can be optimized. There must be a gap of at least 6 hours between resizes. For larger databases, there should be a gap of 6 to 24 hours for each terabyte of data.

Refer to the autoscaling size increases to check the next few tiers of storage. If you expect your database to outgrow an upper tier while still optimizing the next tier, you should manually scale your database to your expected final size. This prevents you from outgrowing your data storage before it can be resized again.

For example, say you have 100 GB of storage. The next two tiers are 125 GB and 150 GB. To resize to 125 GB, AWS needs to modify the underlying storage volume. This can typically happen within 6 hours, but it might take 24 hours in some cases. The time doesn't always scale linearly with the volume size. For safety, you might want to leave 24 hours.

Resizing is triggered when your disk is 85% full, so the first resize is triggered at 85 GB, and the second resize is triggered at 118 GB. If you expect your data to grow from 85 GB to 118 GB within a day, you should manually resize your storage to accommodate the heavy load.

Size increase gradations

Size increases occur with these gradations:

• 10 GB
• 25 GB
• 50 GB
• 75 GB
• 100 GB
• 125 GB
• 150 GB
• 175 GB
• 200 GB
• 225 GB
• 250 GB
• 275 GB
• 300 GB
• 325 GB
• 350 GB
• 375 GB
• 400 GB
• 425 GB
• 450 GB
• 475 GB
• 500 GB
• 600 GB
• 700 GB
• 800 GB
• 900 GB
• 1 TB
• 1.5 TB
• 2 TB
• 2.5 TB
• 3 TB
• 4 TB
• 5 TB
• 6 TB
• 7 TB
• 8 TB
• 9 TB
• 10 TB
• 12 TB
• 14 TB
• 16 TB