Skip to main content
This page explains Cockroach Labs’ policy for supporting production releases of CockroachDB self-hosted. For clusters deployed in Cloud, refer to the CockroachDB Cloud Support and Upgrade Policy. There are two major release types: Regular and Innovation releases. Each offers a unique set of Support Types, which define the durations for each support phase.

​
Support phases

  • Maintenance Support: Begins for a CockroachDB major version upon its GA release. During this phase:
    • Cockroach Labs will produce regular patch releases that include critical security fixes and resolutions to problems identified by users.
    • Cockroach Labs may backport non-breaking enhancements produced for newer major versions.
    • Cockroach Labs may direct customers to workarounds or other fixes applicable to a reported case.
    • Cockroach Labs may recommend that customers upgrade to a later version of the product to resolve or further troubleshoot an issue.
  • Assistance Support: Immediately follows the Maintenance Support phase for Regular releases. Innovation releases do not have an Assistance Support phase. During this phase:
    • Feature enhancements will no longer be made available to the major release.
    • Cockroach Labs will continue to add critical security fixes to the major release in the form of patch releases.
    • Patch releases for the purpose of resolving bugs or other errors may no longer be made to the major release.
    • Cockroach Labs may direct customers to workarounds or other fixes applicable to the reported case.
    • Cockroach Labs may direct customers to upgrade to a later version of CockroachDB to resolve or further troubleshoot an issue.
  • Unsupported: The day that a major version’s final support period ends is its unsupported date. After a version reaches end of life, Cockroach Labs provides no further support for the release.
    • A Regular release reaches unsupported at the Assistance Support phase’s end date.
    • An Innovation release reaches unsupported at the Maintenance Support phase’s end date.

​
Support types

​
Regular releases

Initially, a Regular release series has GA Support. After the series demonstrates a continuously high level of stability and performance, new patch releases are designated as LTS releases, which have an extended support window for each support phase: Maintenance Support, Assistance Support, and Unsupported versions.
  • GA Support: The default support type for production releases, starting with the initial production release of a major version, followed by each subsequent patch release before LTS releases begin for that major version.
    • Maintenance support ends:
      • 365 days after the day of the first production release of the major version (i.e. the ‘GA release,’ ending in.0).
    • Assistance support ends:
      • 180 days after the Maintenance Support end date of the release.
    • Major versions prior to v23.1 will not have LTS releases.
  • LTS (Long-Term Support): Conferred to an initial LTS maintenance release of a given major version and its subsequent maintenance releases. LTS provides extended support windows while also indicating our highest level of expected release stability and performance.
    • Maintenance support ends:
      • 365 days after the day of the first LTS release of the major version.
    • Assistance support ends:
      • 365 days after the Maintenance Support end date of the release.

​
Innovation releases

Innovation releases do not have LTS releases.
  • Innovation Support:
    • Maintenance Support ends:
      • 180 days after the day of the first production release of the major version.
Innovation releases are not eligible for Assistance Support, and reach EOL at the end of Maintenance Support.

​
Major-version upgrade paths

A cluster can always be upgraded to the next major version. Beyond that, the supported direct upgrade paths depend on the release type of the version the cluster is running:
  • From a Regular release, a cluster can be upgraded directly to either the next major version (an Innovation release) or the Regular release that follows it, skipping the Innovation release.
  • From an Innovation release, a cluster can be upgraded only to the next Regular release.
  • From the .4 Regular release of a given year, starting with v26.4, a cluster can also be upgraded directly to the .4 Regular release of the following year, skipping the .1, .2, and .3 releases in between. Refer to Annual upgrade path.
Upgrading directly between two Innovation releases is not supported. To upgrade a cluster from a version that is not a supported source for the target version, first upgrade to an intermediate version that is.

​
Annual upgrade path

Starting with v26.4, the .4 Regular release of each year accepts a direct upgrade from the .4 Regular release of the previous year. A cluster running v26.4 can be upgraded directly to v27.4 without first upgrading to v27.1, v27.2, or v27.3, and a cluster running v27.4 can be upgraded directly to v28.4. This allows a cluster to stay on a supported version with one major-version upgrade per year. Because each .4 release is a Regular release whose patch releases are later designated LTS, the annual upgrade path is also an LTS-to-LTS upgrade path: a cluster can move from one year’s LTS release to the next year’s LTS release in a single upgrade. The path is defined by major version, so it is available as soon as the target .4 release is GA and does not require either version to have reached its LTS designation. To upgrade only between LTS releases, wait until the target .4 release has LTS patch releases, then upgrade directly to one of them from the previous .4 release. The .2 Regular releases are unchanged by this path. Each .2 release remains a Regular release, remains eligible for LTS, and keeps the same support windows. It is an optional stop between two .4 releases rather than a required one. Support windows for all release types are also unchanged. Keep the following in mind when planning an upgrade between .4 releases:
  • The annual upgrade path is a single supported hop between consecutive .4 releases. It is not a general guarantee that any major version can be skipped. For example, a cluster running v27.1 cannot be upgraded directly to v27.4.
  • Upgrading to v26.4 itself is unchanged. A cluster must be running v26.2 or v26.3 to upgrade to v26.4.
  • An upgrade between .4 releases applies the migrations for every skipped major version. Finalizing the upgrade can take roughly twice as long as finalizing an upgrade from the previous major version. Plan the upgrade window accordingly.
  • Before upgrading, review the release notes for the target version and for every skipped major version, paying particular attention to backward-incompatible changes, deprecations, and changes to cluster setting defaults. For the upgrade procedure, refer to Upgrade CockroachDB self-hosted.
For clusters deployed in CockroachDB Cloud, refer to the CockroachDB Cloud Support and Upgrade Policy.

​
Supported versions

*: This major version will receive LTS patch releases, which will be listed on an additional row, upon their availability. **: This major version is an optional innovation release and will not receive LTS patch releases. Innovation releases are EOL when Maintenance Support ends.

​
Unsupported versions

The following versions of CockroachDB are no longer supported. Once a major version is older than four years from its GA release date, the links to its binaries and corresponding Docker images will be unpublished. *: This EOL major version is an optional innovation release. Innovation releases do not receive LTS releases and are EOL when Maintenance Support ends.