Use this guide to scale your Tair (Redis OSS-compatible) instance up or down. Upgrade to handle increased traffic, or downgrade to reduce costs during periods of lower usage.
Billing
Billing depends on your payment method:
| Billing method | What happens |
|---|---|
| Subscription | Pay the price difference for an upgrade, or receive a refund for a downgrade. |
| Pay-as-you-go | Billed based on the new specifications. |
For pricing details, see Configuration changes.
Limitations
Check the following constraints before starting:
| Constraint | Details |
|---|---|
| Memory floor for downgrades | After a downgrade, used memory cannot exceed 80% of the new memory capacity. For example, if your DRAM-based instance currently has 2 GB in use, you cannot downgrade to less than 2.5 GB. |
| Distributed instances | All child instances within a distributed instance must have identical specifications. Mixed specifications are not supported. |
| ESSD-based instances | Storage capacity can only increase, in increments of 10 GB. Decreasing storage is not supported. |
| CPU-only upgrades | You cannot upgrade CPU independently. To increase available CPU cores, switch to cluster architecture, enable read/write splitting, add read-only nodes, or add shards. |
Change instance specifications
What stays the same
When you change specifications, the following remain unchanged — no application code changes are required:
-
Endpoints
-
Database accounts and passwords
-
Whitelist settings
Instance data is preserved. In the rare case where the primary node fails during switchover, a small amount of unsynchronized data may be lost.
Service impact
The degree of service interruption depends on your instance type and host resource availability.
| Scenario | Service interruption |
|---|---|
| Cloud-native instance on a host with sufficient resources | None. Services continue without interruption. |
| Cloud-native instance on a host with insufficient resources, or any classic instance | 1-2 transient disconnections, each lasting less than 30 seconds. Make sure your application reconnects automatically. |
When a switchover occurs, the instance is also read-only for about one minute to ensure fast data sync and prevent dual-write issues caused by DNS caching. For instances with high write volumes, this period may be longer.
During the change, the minor version of your instance is automatically upgraded to the latest. Minor versions are backward-compatible.
Steps
-
Log in to the Instances page. In the top navigation bar, select the region where your instance resides, then click the instance ID.
-
In the upper-right corner, click Specification Adjustment, then select the appropriate option:
-
Subscription instance: Select Specification Upgrade or Specification Downgrade.
-
Pay-as-you-go instance: Select Specifications Upgrade/Downgrade.
-
-
On the page that appears, select the target specifications.
-
Set the Switching Time:
-
Switch Within Maintenance Window (recommended): The system applies the change during the configured maintenance window (off-peak hours). To adjust the timing before the switchover, go to Task Center and click Change Switching Time next to the task.
-
Switch after Data Migration: The system switches to the new node immediately after data migration completes.
-
-
Click Buy Now and complete the payment.
After you submit, the instance status changes to Changing Configuration. The system begins requesting resources and syncing data in the background — your services are not affected at this stage. Transient disconnections only occur at the moment of switchover to the new node.
How specification changes work
Understanding the underlying process helps you predict when interruptions may occur.
Cloud-native instance
-
The instance enters the Changing Configuration state.
-
The system checks whether the current host has enough resources for the target specifications.
-
Based on available resources, the system takes one of two paths:
-
Sufficient resources: The specification change completes in-place with no interruption.
-
Insufficient resources: The system provisions a new host node, pre-syncs the instance data to it, then switches traffic to the new node within the maintenance window (or immediately). This causes a brief transient disconnection.
-
-
The instance returns to the Running state.
Classic instance
-
The instance enters the Changing Configuration state.
-
The system provisions a new host node and pre-syncs the instance data to it.
-
The system switches traffic to the new node within the maintenance window (or immediately). This causes a brief transient disconnection.
-
The instance returns to the Running state.
FAQ
Can I upgrade only the CPU without changing memory?
No. Tair (including Redis Open-Source Edition) does not support upgrading CPU independently. To increase available CPU cores, use one of the following approaches:
-
Switch from standard to cluster architecture, or enable read/write splitting.
-
Add read-only nodes (for instances with read/write splitting enabled).
-
Add shards (for cluster instances).
For more details, see How to upgrade the CPU specifications of an instance and Instance types and FAQ.