Smooth Scaling improves how eligible Redis Cloud Pro databases redistribute hash slots when capacity changes. It is designed to shorten scaling operations, reduce unnecessary data movement, and minimize connection interruptions while the database remains available where possible.
Use this guide to:
Determine whether Smooth Scaling applies.
Distinguish expected temporary effects from a failed or degraded operation.
Validate the resulting configuration.
Collect the information Redis needs to investigate an issue.
This article explains eligibility, expected behavior, and troubleshooting. Use the Redis Cloud documentation for scaling prerequisites and instructions.
Quick Fix
| What you see | Likely explanation | What to do |
|---|---|---|
| Smooth Scaling is not shown as an option | Eligible databases use it automatically; there is no separate customer-facing setting. | Confirm eligibility and account rollout availability. |
| Scaling uses the previous behavior | The database is ineligible or the gradual rollout has not reached the account. | Confirm the database version (8.4 minimum), hashing policy, database type, and account availability. |
| Brief latency or throughput variation occurs | Live slot movement can temporarily affect traffic. | Monitor until the operation completes and compare with the pre-scaling baseline. |
| The scaling operation remains in progress unusually long | The dataset, requested change, workload, or platform condition may be extending the operation. | Do not submit overlapping changes. Capture the start time and contact Redis Support if progress stops. |
| The operation reports a failure | Redis Cloud could not complete the requested configuration. | Verify the configuration that remains active before retrying. Contact Redis Support if errors persist or repeat. |
| Latency remains high after completion | The new capacity, workload distribution, client behavior, or another resource may be responsible. | Compare post-change metrics with the baseline and validate the applied configuration. |
Eligibility
Smooth Scaling is rolling out gradually across Redis Cloud Pro accounts. When available, it is applied automatically to databases that meet all of these conditions:
Redis database version 8.4 or later.
Selecting the Redis hashing policy.
RAM-based database.
Not an Active-Active database.
Not a Redis Flex database.
Smooth Scaling does not currently apply to:
Active-Active databases.
Redis Flex databases.
Databases using the standard or custom hashing policies.
An ineligible database can still be scaled through the existing Redis Cloud scaling process.
Before scaling
Establish a baseline. Record:
Dataset size and memory utilization.
Ops/sec and request latency, including tail latency.
Client connections and error rate.
Current throughput and memory configuration.
Database version and hashing policy.
Start time of the planned change in UTC.
Check application readiness:
When the OSS cluster API is enabled, use supported Redis clients that handle cluster topology changes correctly.
Confirm retry and timeout behavior is appropriate for a live scaling event.
Avoid unrelated configuration changes during the scaling window.
Schedule changes during a lower-traffic period when the workload is latency-sensitive.
Smooth Scaling is designed to reduce the impact of scaling, but it does not guarantee that every workload will experience no latency or throughput change.
Step 1: Confirm Smooth Scaling eligibility
In the Redis Cloud console, confirm that:
The subscription is Redis Cloud Pro.
The database runs Redis 8.4 or later.
The database uses the Redis/OSS hashing policy.
The database is RAM-based.
The database is not Active-Active.
The database is not Redis Flex.
When using Smooth Scaling, the UI will display a progress bar. This is how the user can confirm that smooth scaling is actually used. With traditional scaling, there won't be a progress bar displayed.
Step 2: Determine whether the behavior is expected
During scaling, Redis Cloud redistributes hash slots while minimizing interruption to database traffic. Depending on the dataset, requested capacity change, and live workload, you might observe:
Temporary latency variation.
A short-lived throughput dip.
A temporary increase in tail latency.
Some retry activity, depending on the client and workload.
There is no standard connection-interruption duration for every operation. Treat the behavior as potentially degraded when:
The database becomes unavailable.
Error rates remain elevated.
Latency does not recover after the operation completes.
The operation shows no progress for an extended period.
The console reports a failure.
The requested configuration is not applied.
Step 3: If the operation appears stalled
Record the operation start time and current status.
Confirm that the database is still serving traffic.
Review latency, throughput, connection, and error metrics.
Check for another database or subscription operation already in progress.
Do not repeatedly submit the same scaling request.
Do not submit a second configuration change while the first remains active.
The duration depends on the amount of data that must move, the size of the requested change, and the workload. With traditional scaling, these operations can take anywhere from several minutes to multiple hours, depending on these factors. Smooth scaling should be faster, but these factors will still affect the time to complete scaling. A previous scaling event is not always an appropriate duration baseline for a different dataset or configuration.
Step 4: If scaling fails
After a reported failure:
Refresh the Redis Cloud console.
Record the displayed error.
Compare the active memory and throughput settings with the requested values.
Confirm application connectivity and database availability.
Review metrics for the period immediately before and during the operation.
Contact Redis Support before retrying if the cause is unclear or the database remains degraded.
Do not assume the service automatically returned to the exact pre-change configuration. Verify the active configuration in the console.
Step 5: Validate the completed operation
After scaling completes:
Confirm that the requested memory and throughput settings are displayed.
Confirm that the database status has returned to its normal state.
Compare latency, throughput, errors, and connections with the baseline.
Confirm that client retries and latency returned to normal.
Run representative application operations.
If performance remains worse, include both the pre-change and post-change measurements when contacting Redis Support.
Scaling down and rollback expectations
Scaling down is a separate capacity change, not an automatic rollback of a prior scale-up operation. Before reducing capacity, confirm that the current dataset and workload fit within the requested limits. Note that scale down is only available in environments with smooth scaling enabled.
Do not use a second scaling request to recover from an active or failed operation unless Redis Support confirms that it is safe.
Contact Redis Support
Open an urgent ticket if the database is unavailable, the application cannot reconnect, or the scaling event is causing significant production impact.
Include:
Subscription and database IDs.
Region and cloud provider.
Database version, type, and hashing policy.
Requested before-and-after capacity.
Operation start time and failure time in UTC.
Exact console status or error.
Screenshots.
Latency, throughput, connection, and error metrics.
Client name and version.
Any simultaneous configuration, networking, or application changes.
Sources
0 comments
Please sign in to leave a comment.