Scaling
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
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:
| 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) |
How scaling works
When you change instance types, 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:
-
Standby provisioning: A new standby instance is created with the target instance type (CPU, memory, and storage configuration)
-
Restore from S3 backups: The standby is initialized by restoring from the most recent backup stored in S3
-
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
-
Replication catch-up: The standby catches up with the primary by streaming and applying ongoing WAL changes
-
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
-
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).
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.
Parallel restore with WAL-G
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 Managed Postgres instance:
- Navigate to the Settings tab of your instance
- In the Scaling section, scroll to Service size
- Select the target instance type
- Review the changes and click "Apply changes"
Scaling strategies
Vertical scaling
Vertical scaling (changing instance types) is the primary method for adjusting resources in 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 (roadmap)
Automatic storage scaling is on the roadmap for Managed Postgres. This feature will automatically increase instance size as your database grows, eliminating the need for manual intervention.
