> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Scaling

> Scale your ClickHouse Managed Postgres instance vertically with flexible VM types and independent resource scaling

export const Image = ({img, alt, size = "lg", background}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} style={{
    backgroundColor
  }} />
      </Frame>
    </div>;
};

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <span>Beta</span>
            </a>;
  }
  return <a href="https://clickhouse.com/docs/reference/settings/beta-and-experimental-features#beta-features" className="betaBadge">
            <span>Beta feature</span>
        </a>;
};

<BetaBadge link="https://clickhouse.com/cloud/postgres" galaxyTrack={true} galaxyEvent="docs.managed-postgres.scaling-beta" />

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.

<h2 id="instance-types">
  Instance types and flexibility
</h2>

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

<Image img="https://mintcdn.com/private-7c7dfe99-trino-dialect/xUD5t8rQeJvNiIFp/images/managed-postgres/instance-types.webp?fit=max&auto=format&n=xUD5t8rQeJvNiIFp&q=85&s=501174eb485c9a8f28698e4bb2048df5" alt="Instance types" size="md" border width="1442" height="3288" data-path="images/managed-postgres/instance-types.webp" />

<h3 id="choosing-instance">
  Choosing the right instance type
</h3>

Different workloads benefit from different resource configurations:

| Workload Type                                     | CPU    | Memory | Storage | Recommended Instance                        |
| ------------------------------------------------- | ------ | ------ | ------- | ------------------------------------------- |
| **Compute optimized**                             | High   | Medium | Medium  | Compute-optimized (high vCPU count)         |
| **Memory optimized** (large working set)          | Medium | High   | Medium  | Memory-optimized (high memory-to-CPU ratio) |
| **Storage optimized** (large datasets, heavy I/O) | Medium | Medium | High    | Storage-optimized (high NVMe capacity)      |

<Tip>
  For safety reasons, you may not be able to switch to instance types whose storage is close to your current used storage capacity. Always opt for instance types with headroom over your current used capacity to avoid any issues.
</Tip>

<h2 id="how-scaling-works">
  How scaling works
</h2>

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

<Image img="https://mintcdn.com/private-7c7dfe99-trino-dialect/xUD5t8rQeJvNiIFp/images/managed-postgres/scaling-settings.webp?fit=max&auto=format&n=xUD5t8rQeJvNiIFp&q=85&s=e4084f450e7f371e5f6337ce1df19a22" alt="Scaling Settings" size="md" border width="2478" height="1742" data-path="images/managed-postgres/scaling-settings.webp" />

<h3 id="scaling-process">
  Scaling process
</h3>

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](https://github.com/wal-g/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

<h3 id="scaling-duration">
  Scaling duration
</h3>

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).

<Warning>
  **Minimal downtime**

  Your application will experience approximately 30 seconds of downtime during the failover, regardless of how long the overall scaling process takes. All the restore and catch-up work happens in the background on the standby instance.
</Warning>

<h3 id="parallel-restore">
  Parallel restore with WAL-G
</h3>

ClickHouse Managed Postgres uses [WAL-G](https://github.com/wal-g/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.

<h3 id="initiating-scaling">
  Initiating a scaling operation
</h3>

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"

<h2 id="scaling-strategies">
  Scaling strategies
</h2>

<h3 id="vertical-scaling">
  Vertical scaling
</h3>

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

<h3 id="read-replicas">
  Read replicas for horizontal scaling
</h3>

For read-heavy workloads, consider using [read replicas](/products/managed-postgres/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.

<h3 id="cdc-scaling">
  CDC scaling for ClickHouse integration
</h3>

If you're replicating data to ClickHouse using [ClickPipes](/products/managed-postgres/clickhouse-integration), 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](/integrations/clickpipes/postgres/scaling)

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

<h2 id="autoscaling">
  Autoscaling
</h2>

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](/products/managed-postgres/monitoring/notifications) 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](/products/managed-postgres/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](https://clickhouse.com/support/program).

<h3 id="autoscaling-cutover">
  Cutover and connections
</h3>

Storage isn't resized in place. Autoscaling follows the same [scaling process](#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](/products/managed-postgres/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](/products/managed-postgres/upgrades#scheduled-upgrades) 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.

<h3 id="autoscaling-read-only">
  Read-only mode
</h3>

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:

| Total disk size | Read-only below | Writes resume above |
| --------------- | --------------- | ------------------- |
| Up to 64 GB     | 1 GB free       | 2 GB free           |
| Up to 128 GB    | 5 GB free       | 7 GB free           |
| Up to 512 GB    | 7 GB free       | 10 GB free          |
| Over 512 GB     | 2% free         | 3% free             |

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.

<h3 id="autoscaling-example">
  Example
</h3>

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.

<h2 id="resources">
  Additional resources
</h2>

* [Settings and configuration](/products/managed-postgres/settings)
* [Read replicas](/products/managed-postgres/read-replicas)
* [High availability](/products/managed-postgres/high-availability)