In our earlier post, we unpacked the mechanics of MySQL HeatWave maintenance, the behind-the-scenes process that keeps your MySQL environments secure, stable, and optimized without changing your database version. We also touched on how Auto Minor Version Upgrades occur when a version reaches the end of its lifecycle. With this update, MySQL HeatWave introduces Configurable Maintenance Windows and Auto-Upgrade Controls, giving you precise control over when maintenance runs and how automatic minor version upgrades are applied. This means you can now align upgrades with your business schedules, minimize disruption, and plan version transitions with confidence, all while maintaining the reliability and compliance you expect from MySQL HeatWave. We are also extending Innovation release available cycle from 3 months to 5 months, this enables customers to stay on the same innovation release version for longer period of time.
Let’s break down what’s new and how it benefits you.
Background and context
Previously, when a MySQL version reached its “unavailable” date, MySQL HeatWave automatically upgraded your DB system to the next available version during the following maintenance cycle. While this ensured your database stayed supported, it gave customers limited control, especially if you wanted to validate the new version in development environments before it reached production.
Now, with the new auto-upgrade options, you can:
- Choose your upgrade schedule — Early or Regular
- Select your target version — Newest, Second Newest, or Oldest
- Plan your testing and rollout windows with clear lifecycle visibility
This means longer periods between mandatory upgrades, smoother testing, and zero surprises when versions phase out.
Understanding the New Options
- When to Auto-Upgrade: Early vs Regular
| Option | Description | Ideal For | Example Scenario |
|---|---|---|---|
| Early | Upgrades your DB system to the newest available version when the current version becomes deprecated. For LTS release, a version is deprecated after 12 months since it’s released. For Innovation release, it is now 5 months (previously 3 month) after its released | Dev/Test environments | Test new version features and compatibility before production rollout |
| Regular | Upgrades your DB system after the version becomes unavailable For LTS release, it is 3 months after the version is deprecated. For Innovation release, it is 1 month after the version is deprecated | Production environments | Ensures production upgrades happen only after thorough validation |
- Auto-Upgrade Version: Newest, Second Newest, or Oldest
This option gives you explicit control over which supported version you move to.
- Newest: Always upgrades to the most recently released version.
- Second Newest: Upgrades to a version that has been tested (ideal for production). For LTS release, the second newest version is tested for 3 months, for Innovation release, it’s 1 month.
- Oldest: Retains the longest-running supported version to minimize change frequency.
This is particularly valuable for customers using Long Term Support (LTS) versus Innovation releases, where version cadence differs.
LTS Releases: Gradual, Predictable Rollout
Let’s take an LTS release cycle example.
Current version: 8.4.2
- Released: July 2024
- Deprecated: July 2025
- Unavailable: October 2025
Next available version: 8.4.6
- Released: July 2025
- Deprecated: July 2026
- Unavailable: October 2026
- With the Early upgrade option, your dev/test systems can move from a deprecated 8.4.2 → 8.4.6 (newest) as soon as 8.4.6 is released (July 2025).
- With the Regular upgrade option, production can be automatically moved from 8.4.2 as soon as it is unavailable to 8.4.6 (second newest) during the October 2025 maintenance window, after a 3-month testing window.
Result: You get a 3-month validation period between dev/test and production upgrades, enabling safe rollout sequencing.
Each MySQL HeatWave version progresses through a lifecycle of Release → Deprecated → Unavailable, and understanding these phases is key to planning your upgrades.
With an LTS version, you typically have:
- Around 12 months between when the LTS version is Deprecated and when the newest version becomes available. This gives your test and development environments ample time to validate, benchmark, and prepare for transition.
- Another 12-month window to move production workloads from a soon-to-be Unavailable version onto the second-newest supported version. Within this period, you can allocate about 3 months of structured testing to ensure application readiness and smooth rollout.
Innovation Releases: Managed Agility
Current version: 9.3.0
- Released: April 2025
- Deprecated: September 2025
- Unavailable: October 2025
Next version: 9.4.2
- Released: September 2025
- Deprecated: February 2026
- Unavailable: March 2026
For Innovation channels (with faster cycles):
- Early option upgrades dev/test to 9.4.2 (newest) immediately upon 9.3.0 becomes deprecated (September 2025).
- Regular option upgrades production when 9.3.0 becomes unavailable (October 2025), making 9.4.2 the second newest and stable choice.
This provides five months of active lifecycle, and a one-month overlap before unavailability, minimizing forced transitions, and 1 month of structured testing.
How to Set Configurable Maintenance and Auto‑Upgrade Controls
You can set maintenance preferences when creating a MySQL HeatWave DB system or update them on existing systems. This ensures maintenance runs in your chosen window and follows your upgrade policy.
During DB system creation:
- Navigate to Databases → MySQL HeatWave → DB systems → Create DB System.
- Select Show Advanced Options and expand Maintenance.
- Turn off “Automatically assigned,” then set:
- Maintenance window: weekday and start time
- Schedule type: Early or Regular
- Version preference: Newest, Second newest, or Oldest
- Create the DB system.
For Existing DB Systems
On the DB system details page, open the Maintenance section.
- Click Edit and update:
- Maintenance window (weekday and start time)
- Schedule type (Early or Regular)
- Version preference (Newest, Second Newest, or Oldest)
- Click Update. Changes take effect in the next scheduled window or the next eligible auto‑upgrade cycle.
Key Benefits and Takeaways
- Flexibility: Choose when and what to upgrade to
- Predictability: Plan dev/test and production rollouts months ahead
- Reduced Disruption: Extend the time between upgrades while staying compliant
- Control: Align your database lifecycle with your internal release rhythm
Summary
With Auto-Upgrade Scheduling and Version Selection, maintenance in HeatWave MySQL evolves from a reactive task into a controlled, strategic process. Whether you prioritize early access or operational stability, you now have the flexibility to fine-tune how and when your databases upgrade, without compromising compliance or uptime. Stay ahead by tracking each version’s Release, Deprecated, and Unavailable dates in the HeatWave MySQL Server Version documentation. Knowing these milestones helps you align upgrade windows with your internal testing and production rollout schedules.
Resources