Scaling

ClickHouse Managed Postgres provides flexible scaling options to match your workload requirements. With 50+ NVMe-backed instance types to choose from, you can independently scale CPU, memory, and storage to optimize performance and cost for your specific use case.

​

Instance types and flexibility

ClickHouse Managed Postgres offers a wide range of instance types, each optimized for different workload characteristics:

• 50+ instance types available across compute, memory, and storage-optimized configurations
• NVMe-backed storage on all instance types for consistent, high-performance disk I/O
• Independent resource scaling: Choose the right balance of CPU, memory, and storage based on your workload

​

Choosing the right instance type

Different workloads benefit from different resource configurations:

​

How scaling works

When you change instance types, ClickHouse Managed Postgres performs a vertical scaling operation that provisions new infrastructure and migrates your database with minimal downtime.

​

Scaling process

The scaling workflow brings up a new standby from backups and performs a controlled failover:

1. Standby provisioning: A new standby instance is created with the target instance type (CPU, memory, and storage configuration)
2. Restore from S3 backups: The standby is initialized by restoring from the most recent backup stored in S3
3. Parallel WAL replay: The standby applies all Write-Ahead Log (WAL) changes since the backup using parallel restore mechanisms powered by WAL-G
   • WAL-G enables fast, parallelized restore operations
   • The creator of WAL-G is on the Ubicloud team with whom we have partnered, ensuring deep expertise and optimization
4. Replication catch-up: The standby catches up with the primary by streaming and applying ongoing WAL changes
5. Failover: Once the standby is fully synchronized, a controlled failover promotes the standby to the new primary
   • This is the only step that causes downtime (~30 seconds)
   • All active connections are interrupted during failover
   • Clients must reconnect after failover completes
6. Old instance decommission: The original instance is decommissioned after the failover completes

​

Scaling duration

The total time required for scaling depends primarily on the size of your database and the amount of WAL data that needs to be replayed from backups:

• Backup restore: Time to restore the most recent full backup from S3 to the new instance
• WAL replay: Time to replay incremental WAL changes since the last full backup
• Parallel restore: WAL-G’s parallel restore mechanisms significantly speed up the process

The restore time can range from a few minutes to a few hours, but the maintenance/downtime is very low (only ~30 seconds).

​

Parallel restore with WAL-G

ClickHouse Managed Postgres uses WAL-G to accelerate backup restoration during scaling operations. Notably, the creator of WAL-G is part of the Ubicloud team who we have partnered with, bringing deep expertise to the restoration process. WAL-G provides:

• Parallel download and decompression: Multiple backup segments are fetched from S3 and decompressed simultaneously
• Efficient WAL replay: Incremental WAL changes are applied in parallel where possible
• Optimized streaming: Direct streaming from S3 storage without intermediate copies
• Fast restoration: While the total time depends on data size, the parallelized approach makes the process quite fast

These optimizations significantly reduce the time required to bring up the new standby instance. Most importantly, the restore happens entirely in the background—your application only experiences downtime during the brief ~30-second failover window.

​

Initiating a scaling operation

To scale your ClickHouse Managed Postgres instance:

1. Navigate to the Settings tab of your instance
2. In the Scaling section, scroll to Service size
3. Select the target instance type
4. Review the changes and click “Apply changes”

​

Scaling strategies

​

Vertical scaling

Vertical scaling (changing instance types) is the primary method for adjusting resources in ClickHouse Managed Postgres. This approach provides:

• Granular control: Choose from 50+ instance types to fine-tune CPU, memory, and storage
• Workload optimization: Select configurations optimized for your specific workload (compute, memory, or storage-intensive)
• Cost efficiency: Pay only for the resources you need without over-provisioning

​

Read replicas for horizontal scaling

For read-heavy workloads, consider using read replicas to scale read capacity horizontally:

• Offload read queries to dedicated read replica instances
• Each read replica is a fully independent Postgres instance with its own compute and memory
• Read replicas stream WAL changes from object storage for efficient replication

This approach is ideal for applications with high read-to-write ratios, such as reporting dashboards, analytics queries, or read-intensive API endpoints.

​

CDC scaling for ClickHouse integration

If you’re replicating data to ClickHouse using ClickPipes, you can independently scale the CDC (Change Data Capture) pipeline:

• Scale CDC workers from 1 to 24 CPU cores
• Memory automatically scales at 4x the CPU core count
• Adjust scaling via the ClickPipes OpenAPI

This allows you to optimize the replication throughput separately from your Postgres instance resources.

​

Autoscaling

ClickHouse Managed Postgres monitors disk usage and scales storage automatically so your instance doesn’t run out of space:

• 85% disk usage: You receive a notification through the cloud console and email.
• 90% disk usage: Autoscaling starts. Storage is increased to the next larger size available for your instance family. CPU and memory stay the same unless the current instance size doesn’t support a larger disk, in which case the instance size is increased as well. Read replicas are scaled alongside the primary.
• 95% disk usage: The cutover happens as soon as the new server is ready, bypassing any wait.

If your instance is already at the largest available configuration, autoscaling can’t go further. Free up disk space or contact support.

​

Cutover and connections

Storage isn’t resized in place. Autoscaling follows the same scaling process as a manual instance type change: a replacement server with more storage is provisioned, restored from the latest backup, catches up on WAL, and a controlled cutover promotes it to the new primary. Instances with high availability get replacement standbys at the new size as part of the same operation. The cutover is the only step with downtime, typically under a minute. A configured scheduled upgrade window doesn’t delay it: the window applies to platform maintenance, not to scaling. During the cutover, open connections are dropped and in-flight transactions are rolled back. Your connection string doesn’t change: DNS is updated to point at the new primary, and applications with standard reconnect logic recover automatically.

​

Read-only mode

If writes fill the disk faster than autoscaling can complete, the instance goes read-only to prevent full disk exhaustion. The trigger is remaining free space: Reads keep working, while writes fail with the standard Postgres error cannot execute INSERT in a read-only transaction. If free space keeps shrinking, existing connections are terminated so that every session picks up the read-only setting; reads work again once clients reconnect. Read-only mode lifts automatically once free space recovers, usually right after the scale-up cutover completes.

​

Example

An instance with 1024 GB of storage runs a write-heavy workload:

1. At 870 GB used (85%), you receive the storage notification.
2. At 922 GB used (90%), autoscaling starts. A replacement server with 2048 GB of storage is provisioned and restored from the latest backup while your instance keeps serving traffic.
3. Once the replacement has caught up, the cutover runs. Connections drop for under a minute, your application reconnects to the same hostname, and usage is back around 45%.
4. If free space drops below 2% (about 20 GB) before the cutover completes, the instance goes read-only. Writes resume automatically once the cutover to the larger disk finishes.

​

Additional resources

• Settings and configuration
• Read replicas
• High availability