Redpanda Supported Versions

Supported Versions

Redpanda Data supports the current Redpanda Enterprise major release line and all prior major release lines from the previous 12 months, giving each major Enterprise release an overall 12-month lifespan from its initial release before reaching “End of Support.” 

We define support for a version as providing regular maintenance releases with bug fixes on the latest major release line, backporting critical bug fixes to earlier supported releases that have not reached their End of Support date, and providing technical support. “Critical bugs” currently include issues involving unmitigated downtime or data loss, or resolving Critical security vulnerabilities (i.e. those with a CVSS rating of 9.0 or above).  

After the End of Support date, no additional patch releases or bug fixes (including security-related fixes) are guaranteed to be made available by Redpanda on the corresponding major release line and Technical Support will be limited to assistance upgrading to a supported version.

We encourage all customers to plan their upgrades as soon as possible and to contact their Customer Success representative if necessary.  

Please review our supported deployment methods in our public documentation.

FAQ:

• “Why should we upgrade?” New major releases deliver not only new features and previously released bug fixes, but also include performance and scale enhancements, as well as observability and supportability improvements not contained in maintenance releases, which means upgrading to the latest major release is the best way to ensure the continued smooth and efficient operation of your Redpanda clusters.

• “Does Redpanda have LTS/STS release designations/trains (e.g. for organizations who want a very stable release with only security patches they can keep in production for > 1 year)?”. No, not currently. With Redpanda, we preserve compatibility with existing Kafka API versions and with other user-facing APIs and configuration settings over long periods of time, across many major versions, eliminating the need to break compatibility and force application changes outside of very rare cases in which APIs are deprecated at least 1 major release in advance. This approach minimizes the need for separate LTS/STS trains. We’ll continue to evaluate whether an LTS/STS model makes sense in the coming years.

Release Breakdown