AWS Database Blog
Knowing when new open source database engine versions release on Amazon Aurora and Amazon RDS
If you’re running or considering Amazon Aurora with PostgreSQL or MySQL compatibility, you’ve likely wondered, “When will the latest community version be available on AWS?” The same question applies if you run Amazon Relational Database Service (Amazon RDS) for PostgreSQL, MySQL, or MariaDB. Whether you want the newest features quickly or prefer to standardize on stable long-term support (LTS) versions, our release timelines help you plan upgrades and maintenance cycles. In this post, we share the version currency timelines for Aurora and RDS open source engines. We also explain why timelines differ across engines and how you can use them to plan your upgrades.
Today, we are publishing version currency timelines for Aurora and RDS open source engines. The timelines apply to new major and minor versions going forward and define when you and your teams can expect new versions on AWS. With this predictability, you can plan maintenance windows, upgrade cycles, and Aurora LTS adoption for workloads that prioritize long-term stability.
| Database engine | Release type | Timeline |
| RDS for PostgreSQL | Minor versions | Within 7 days of community release |
| Major versions | Within 30 days of the community <major>.1 release |
|
| RDS for MySQL | Minor versions | Within 30 days of community release |
| Major versions | Within 6 months of community <major>.1 release (Oracle MySQL LTS majors) |
|
| RDS for MariaDB | Minor versions | Within 30 days of community release |
| Major versions | Within 3 months of community’s first patch release | |
| Aurora PostgreSQL | Minor versions | Within 3 months of community release |
| Major versions | Within 8 months of the community <major>.1 release |
|
| Aurora LTS per major | Within 12 months of Aurora major GA | |
| Aurora MySQL | Minor versions | Within 3 months of community release |
| Major versions | Within 12 months of community <major>.1 release (Oracle MySQL LTS majors) |
|
| Aurora LTS per major | Within 12 months of Aurora major GA |
For the current schedule of upcoming and recently shipped versions, including specific version numbers and target dates, see the release calendar linked from each engine name in the table.
Why timelines differ across engines
The timelines differ by engine because the upstream development and integration models differ. PostgreSQL and MariaDB communities develop in the open, which lets us start validation early. MySQL commits are available closer to public releases. RDS runs the community engine on managed infrastructure, so after a community release passes validation it can ship quickly. Aurora adds a distributed storage layer, Global Database, and serverless capabilities underneath PostgreSQL- and MySQL-compatible engines. Every new version goes through additional validation to verify that those capabilities continue to function correctly. This is why Aurora timelines are longer than RDS timelines for the same engine. Aurora also offers Long-Term Support releases for multi-year stability on a single minor version.
How we choose major version starting points
For PostgreSQL, our first production release of a new major version is typically based on the community <major>.1 release rather than <major>.0. The <major>.1 release generally arrives roughly three months after the initial major release. It incorporates the first round of bug fixes and security patches identified during early production deployments, which provides a more stable starting point for production workloads.
MariaDB follows a similar pattern. The published major version timelines are measured from the community’s first patch release for a new major version rather than the initial <major>.0 release. This gives customers a more mature production baseline to target.
For MySQL, the major version timelines apply to Oracle MySQL LTS major releases and are measured from the corresponding <major>.1 release. This aligns the timelines to the first patch release after the initial LTS major becomes generally available.
What this means for your upgrade planning
Published version currency timelines give you and your teams earlier visibility into release planning and upgrade scheduling. With RDS for PostgreSQL minor versions arriving within 7 days of community release, teams can stay current on security patches and bug fixes with relatively little operational planning. You can enable automatic minor version upgrades to receive patches during maintenance windows. You can also use AWS Organizations upgrade rollout policies to manage deployment sequencing across your development, test, and production environments, or apply upgrades manually based on your own operational processes.
Earlier visibility into major version timelines helps your teams adopt new database capabilities on your own schedule. Knowing when a new version is expected on Aurora or RDS gives teams more time to review release notes, validate application behavior, and prepare rollout plans ahead of adoption. With RDS Database Preview, you get early access to PostgreSQL and MySQL major versions in a non-production environment so you can test application compatibility in advance. With Blue/Green Deployments, you can validate changes before cutover and transition production traffic with minimal downtime.
With Aurora LTS releases, you can prioritize operational stability over rapid feature adoption. Your teams can remain on a stable minor baseline for multiple years while aligning major version upgrades with broader application and infrastructure roadmaps.
For workloads approaching or beyond community end-of-life timelines, Amazon RDS Extended Support gives you additional time to finish upgrades while continuing to receive critical security updates.
Learn more
For detailed upgrade procedures and release guidance, see the Amazon Aurora User Guide and the Amazon RDS User Guide.