AnalyticDB for PostgreSQL supports vertical scaling (changing node specifications) and horizontal scaling (adding or removing compute nodes). Both methods adjust CPU, memory, disk, and compute capacity online without taking the instance offline.
Scaling methods compared
| Change node specifications | Add or remove compute nodes | |
|---|---|---|
| What changes | CPU, memory, and disk of existing nodes | Number of nodes with the same specifications |
| Data redistribution | Not required | Required |
| Estimated time | About 10 minutes | 30 minutes to several hours (elastic storage mode) or under 5 minutes (serverless mode) |
| Best for | CPU or memory bottlenecks with low I/O utilization | High CPU and I/O utilization across nodes |
When to use each method:
View node monitoring data to identify bottlenecks before scaling.
High CPU and I/O utilization during business hours -- add compute nodes.
High CPU or memory usage but low I/O utilization -- upgrade node specifications.
High disk usage but sufficient computing resources -- increase only the node storage capacity when upgrading node specifications. This avoids the cost of adding compute nodes.
To downgrade resources, downgrade node specifications first. If the specifications cannot be downgraded further, remove compute nodes.
Supported operations by resource type
| Operation | Serverless mode | Elastic storage mode |
|---|---|---|
| Upgrade node specifications | Not supported | Supported |
| Downgrade node specifications | Not supported | Supported |
| Add compute nodes | Supported | Supported |
| Remove compute nodes | Supported | Supported |
Time estimates
Change node specifications
About 10 minutes.
Add or remove compute nodes (elastic storage mode)
30 minutes to several hours, depending on data volume. Factors include the number of tables, partitioned tables, indexes, compression status, total data volume, and node specifications.
Use this formula to estimate the time:
Time (min) = Total data volume (GB) / 1.25 / Number of nodes after change + 30The 30-minute overhead covers resource provisioning and setup.
Example: Scale out an instance with 1 TB of data to 16 nodes:
1024 / 1.25 / 16 + 30 = 81 minutesFor instances with minor engine version earlier than V6.6.2.0 or V7.0.5.0, tables being redistributed may become temporarily unavailable for read and write operations. Retry the operation later if this occurs. For instances with minor engine version V6.6.2.0 or later, or V7.0.5.0 or later, read and write operations are not interrupted when you add compute nodes.
Add or remove compute nodes (serverless mode)
Serverless mode supports online elastic scaling within minutes. No data migration is required, so scaling speed depends on resource provisioning rather than data size.
| Instance size | Estimated time |
|---|---|
| 16 nodes or fewer | 60 seconds or less |
| More than 16 nodes | 5 minutes or less |
Prerequisites
An AnalyticDB for PostgreSQL instance in elastic storage mode or serverless mode
To remove compute nodes from an instance in elastic storage mode, the minor engine version must be V6.3.10.5 or later for AnalyticDB for PostgreSQL V6.0, or V7.0.1.2 or later for AnalyticDB for PostgreSQL V7.0. For more information, see View the minor engine version of an instance.
For instances in elastic storage mode with minor engine version V6.6.2.0 or later, or V7.0.5.0 or later, both read and write operations are supported when you add compute nodes. Earlier versions support only read operations. When you remove compute nodes, data write operations may be affected.
Usage notes
When you remove compute nodes from an instance in elastic storage mode, make sure that the instance has enough capacity to store existing data after the scale-in operation.
Changing the compute nodes of an instance in serverless mode interrupts running SQL statements. These statements cannot be resumed after the change is complete.
During online scale-out (adding compute nodes with minor engine version V6.6.2.0 or later, or V7.0.5.0 or later in elastic storage mode):
Queries and the INSERT, COPY, DELETE, and UPDATE commands are supported for tables being redistributed.
DDL commands and the VACUUM command are not supported for tables being redistributed. For example:
TRUNCATE t1; ERROR: Unsupport 'TRUNCATE TABLE' command during online expansion on 't1'Large volumes of data writes and updates extend the time required for the configuration change.
A write lock may be applied to frequently written tables after a certain period to optimize redistribution speed. This may briefly affect read and write operations on those tables. Monitor the scale-out progress in the AnalyticDB for PostgreSQL console.
For instances with earlier minor engine versions, online scaling is not supported when you add compute nodes. This process may interrupt read and write operations on tables. Perform this operation during off-peak hours.
Add compute nodes
Log on to the AnalyticDB for PostgreSQL console.
In the upper-left corner of the console, select a region.
Find the target instance. In the Actions column, choose Change Compute Node Configurations > Add Compute Nodes.
In the Notice dialog box, select I am aware of the impact of this operation and agree to continue it. and then click OK.
NoteThis step is required only for instances in serverless mode.
On the Upgrade/Downgrade page, select an appropriate value for Number Of Nodes (segment), select the Terms of Service, and then click Buy Now.
WarningInstances in elastic storage mode: Tables being redistributed become read-only during the configuration change. Newer versions support both read and write operations. The redistribution time depends on the table size. Plan the task accordingly. Instances in serverless mode: After you submit the configuration change task, running SQL statements are interrupted and cannot be resumed.
Return to the Instance List page. Wait for the status of the target instance to change to Running.
(Serverless mode only) For tables with high performance requirements, run the following SQL statement to prefetch data and accelerate access:
NoteScaling nodes in or out involves five steps: resource initialization, system table metadata synchronization, locking to protect and modify data distribution information, unlocking and clearing resources, and asynchronous local cache recovery. Because the local cache is restored asynchronously, the cache hit ratio may be low for a short period. Prefetching data accelerates access.
SELECT count(*) FROM <hot_table>;
Remove compute nodes
When you remove compute nodes from an instance in elastic storage mode, make sure that the instance can accommodate existing data after the scale-in. Reduce data update and write operations on the instance during the scale-in period.
Log on to the AnalyticDB for PostgreSQL console.
In the upper-left corner of the console, select a region.
Find the target instance. In the Actions column, choose Change Compute Node Configurations > Remove Compute Nodes.
In the Notice dialog box, select I am aware of the impact of this operation and agree to continue it. and then click OK.
On the Upgrade/Downgrade page, select an appropriate value for Number Of Nodes (segment), select the Terms of Service, and then click Buy Now.
WarningInstances in elastic storage mode: Tables being redistributed become read-only during the configuration change. The redistribution time depends on the table size. Plan the task accordingly. Instances in serverless mode: After you submit the configuration change task, running SQL statements are interrupted and cannot be resumed.
Return to the Instance List page. Wait for the status of the target instance to change to Running.
(Serverless mode only) For tables with high performance requirements, run the following SQL statement to prefetch data and accelerate access:
NoteScaling nodes in or out involves five steps: resource initialization, system table metadata synchronization, locking to protect and modify data distribution information, unlocking and clearing resources, and asynchronous local cache recovery. Because the local cache is restored asynchronously, the cache hit ratio may be low for a short period. Prefetching data accelerates access.
SELECT count(*) FROM <hot_table>;
Upgrade node specifications
Log on to the AnalyticDB for PostgreSQL console.
In the upper-left corner of the console, select a region.
Find the target instance. In the Actions column, choose Change Compute Node Configurations > Upgrade Node Specifications.
On the Upgrade/Downgrade page, modify the following configurations:
WarningThe database becomes read-only during the node specification change. Plan the task accordingly. The instance supports read and write operations when only the node storage capacity is changed.
Configuration Description Instance Resource Type The resource type of the current instance. This value cannot be changed. Node Specifications (segment) Select appropriate node specifications as needed. Node Storage Capacity (segment) Select an appropriate node storage capacity as needed. Select the Terms of Service, and then click Buy Now.
Return to the Instance List page. Wait for the status of the target instance to change to Running.
Downgrade node specifications
Log on to the AnalyticDB for PostgreSQL console.
In the upper-left corner of the console, select a region.
Find the target instance. In the Actions column, choose Change Compute Node Configurations > Downgrade Node Specifications.
On the Upgrade/Downgrade page, modify the following configurations:
WarningThe database becomes read-only during the node specification change. Plan the task accordingly. The instance supports read and write operations when only the node storage capacity is changed.
Configuration Description Instance Resource Type The resource type of the current instance. This value cannot be changed. Node Specifications (segment) Select appropriate node specifications as needed. Node Storage Capacity (segment) Reducing the node storage capacity is not supported. This configuration is not available for Basic Edition instances in elastic storage mode. Select the Terms of Service, and then click Buy Now.
Return to the Instance List page. Wait for the status of the target instance to change to Running.