Redis Cloud manages database versions to keep deployments on secure, stable, and supported Redis releases while maintaining customer control over major version upgrades.
This article explains how Redis Cloud handles Redis version updates. It shows what types of upgrades are applied automatically, which upgrades require customer action, and how version lifecycle policies affect running databases.
Versioning and Compatibility Policy
How does Redis versioning work?
Redis follows semantic versioning (SemVer 2.0.0):
MAJOR versions (for example, Redis 7 → Redis 8) may introduce incompatible changes in rare cases.
MINOR versions (for example, Redis 8.4 → 8.6) introduce new features and improvements and are designed to be backward compatible.
PATCH versions include backward-compatible bug fixes and security updates.
What compatibility guarantees does Redis provide?
Redis is designed to avoid breaking changes wherever possible, especially in MINOR releases.
Specifically:
MINOR releases are intended to be backward compatible for versions that have not reached their end of life, without breaking API or behavior changes.
MINOR releases are engineered to avoid performance regressions. Redis maintains a comprehensive performance and regression test suite, and we continuously optimize the core to offset the cost of new features.
Note: In rare cases, a new feature or internal change could impact performance for a particular workload or environment. Redis mitigates this with extensive automated and real-world performance testing, and when regressions are detected, fixes and optimizations are prioritized so that releases remain within expected performance bounds (In exceptional cases, a release may cause a minor regression (up to ~2%), and it often delivers net improvements.).
Redis Cloud Version Lifecycle Policy
What are STS and LTS releases?
Redis Cloud classifies MINOR releases into two support categories:
Short-Term Support (STS)
All MINOR releases except the second and final MINOR of a MAJOR version
Supported until six months after the following MINOR release
Long-Term Support (LTS)
The second MINOR and the final MINOR of a MAJOR version
Supported for five years since the introduction in the Redis platform
Example for Redis 8:
Redis 8.2 is an LTS release
Redis 8.4 and 8.6 are STS releases
The final Redis 8.x release before Redis 9.0 will also be LTS
LTS releases are intended for customers who prefer long-term stability and fewer version changes.
What Is Changing With This Version Update?
Starting with Redis 8.4, Redis Cloud standardizes how MINOR versions are maintained within a MAJOR release.
Instead of requiring customers to manually manage every minor upgrade, Redis Cloud can keep databases on supported MINOR versions automatically, based on the lifecycle policy described above.
MAJOR version upgrades remain fully customer-controlled.
Automatic Minor Version Upgrades
How are minor version upgrades handled?
For Redis 8.4 and later, Redis Cloud may automatically upgrade databases to newer MINOR versions within the same MAJOR release.
This ensures databases receive:
Security fixes
Bug fixes
Performance improvements
New backward-compatible features
Upgrades:
Never change the MAJOR version
Occur only during scheduled maintenance windows
Are included in standard maintenance notifications
Can customers control minor version upgrades?
Control depends on the Redis Cloud plan:
Redis Cloud Pro
Automatic minor upgrades are enabled by default
Customers can opt out of minor auto-upgrades per database
Redis Cloud Essentials
Automatic minor upgrades are always enabled
Customers cannot opt out
Versions older than 8.4 are not auto-upgraded (e.g., Redis 8.2 is not automatically upgraded to Redis 8.4).
What happens if a database remains on an older minor version?
If a database remains on a MINOR version that reaches End of Life (EOL), Redis Cloud will upgrade it during the subscription’s maintenance window to keep the database on a supported version.
Customers receive advance notice before any such upgrade occurs.
Operational Behavior and Impact
When do upgrades occur?
During the subscription’s configured maintenance window
As part of the cluster upgrade process (AKA system update)
The deployed Redis version is always visible in the Redis Cloud Console, API and Terraform.
What is the expected impact during upgrades?
Impact depends on database configuration:
With replication enabled
No downtime expected
Possible brief latency spikes during shard failover
Without replication
Temporary downtime expected during shard restart
Most upgrades complete in under one minute per database.
0 comments
Please sign in to leave a comment.