Should I upgrade to YugabyteDB STS vs LTS Upgrade Path Before 2025.1 STS Maintenance Ends July 23, now?
Decide whether production clusters on YugabyteDB 2025.1 STS should stay on the short-term track or move to an LTS release before maintenance support ends on July 23, 2026; evaluate deployment-model-specific upgrade-path caveats separately.
Blockers
- package/yugabytedb-2025-1-sts — EOL 2026-07-23
- If converting cron-based universes to systemd from earlier than v2024.2.8, you must first upgrade to v2024.2.8 or later.
- YugabyteDB Anywhere v2025.2 and later require node agent on universe nodes except Kubernetes.
- package/yugabytedb-2025-2-lts incompatible with capability/cron-based-universes
- package/yugabytedb-anywhere incompatible with package/yugabytedb-2025-2-lts
Who this is for
- enterprise
- low-ops
- compliance
Candidates
Move to YugabyteDB 2025.2 LTS before July 23, 2026
YugabyteDB v2025.2 is the current LTS stable release, with maintenance support through December 11, 2027, while v2025.1 STS maintenance ends on July 23, 2026. This is the safer default if you need maintenance updates beyond that date and want to avoid entering 2025.1 extended support.
When to choose
Use this when the cluster must keep receiving maintenance updates after July 23, 2026 and you can meet the applicable upgrade prerequisites now: self-hosted estates can complete upgrade testing without an active change freeze, YugabyteDB Anywhere environments can satisfy node-agent, systemd, and control-plane version requirements without a blocking migration path, and managed deployments do not have service-specific upgrade blockers.
Tradeoffs
Longer maintenance window and lower support risk, but you must clear upgrade prerequisites first and test operational changes before cutover.
Cautions
For YugabyteDB Anywhere, v2025.2 and later require node agent on universe nodes except Kubernetes, and cron-based universes are no longer supported. If you are on a version earlier than v2024.2.8 and need to convert cron-based universes to systemd, Yugabyte says you must first upgrade to v2024.2.8 or later. Backups taken on a newer version cannot be restored to universes running a previous version.
Stay on YugabyteDB 2025.1 STS only long enough to clear blockers, then upgrade
As of 2026-04-04, YugabyteDB v2025.1 STS is still in maintenance support, but only until July 23, 2026. After the maintenance period, Yugabyte's support policy says the series moves into 180 days of extended support, where updates and upgrades are not made to that minor release and customers may be directed to existing workarounds or to upgrade to a current release. This makes 2025.1 a short runway for production if you need active fixes after July 2026. The only justified reason to remain on 2025.1 is temporary operational blockage, not as a steady-state plan.
When to choose
Use this only when a near-term move to 2025.2 is blocked by systemd migration, node-agent rollout, deprecated OS work, or change-freeze timing. The decisive factor is whether those blockers can be cleared well before July 23, 2026.
Tradeoffs
Avoids an immediate platform change, but compresses testing and rollout time and leaves you with a support posture that no longer receives maintenance updates after July 23, 2026.
Cautions
If you run YugabyteDB Anywhere, you cannot use it to deploy a YugabyteDB version newer than the YBA instance, so the control plane may need upgrading first. For Aeon upgrades, the official flow includes a 48-hour monitor window to roll back or finalize, and some upgrade types block DDL during the upgrade window.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to YugabyteDB STS vs LTS Upgrade Path Before 2025.1 STS Maintenance Ends July 23, now?"