AWS Publishes Aurora and RDS Version Currency SLAs

Anyone who has ever tried to schedule a Postgres major upgrade for a payments platform knows the real bottleneck isn't the pg_upgrade command. It's the calendar. Product wants the new feature, security wants the CVE closed, and nobody at AWS has ever told you, on paper, when the version will actually land in the console. That changed this week.

AWS has now published version currency timelines for Aurora and RDS across PostgreSQL, MySQL, and MariaDB. For the first time, platform leads have a documented window they can put on a roadmap without hedging.

What Happened

As Amazon Web Services (AWS) reported, the company is publishing target windows that apply to new major and minor versions going forward. The numbers are specific enough to plan against and varied enough to explain why your Aurora upgrades never felt as fast as RDS.

Start with RDS. Minor versions of RDS for PostgreSQL land within 7 days of community release. RDS for MySQL and MariaDB minors land within 30 days. Major versions of RDS for PostgreSQL arrive within 30 days of the community <major>.1 release. RDS for MariaDB majors land within 3 months of the community's first patch release. RDS for MySQL majors get 6 months from the community <major>.1, and only for Oracle MySQL LTS majors.

Aurora runs slower, by design. Aurora PostgreSQL minors ship within 3 months of community release. Aurora PostgreSQL majors within 8 months of the community <major>.1. Aurora MySQL minors within 3 months. Aurora MySQL majors within 12 months of the community <major>.1. Aurora LTS releases per major arrive within 12 months of the Aurora major GA on both engines.

AWS also explained the starting points. Postgres production releases on AWS are typically based on the community <major>.1, which usually arrives about three months after the initial major. MariaDB timelines are measured from the community's first patch release. MySQL timelines apply only to Oracle MySQL LTS majors, measured from <major>.1.

The company reiterated the surrounding toolchain: automatic minor version upgrades during maintenance windows, AWS Organizations upgrade rollout policies, RDS Database Preview for early testing, Blue/Green Deployments for cutover, and Amazon RDS Extended Support for workloads past community end-of-life.

Technical Anatomy

The gap between RDS and Aurora timelines is the interesting engineering story here. AWS attributes it to two things: how upstream communities develop, and what Aurora adds underneath the engine.

PostgreSQL and MariaDB develop in the open. AWS can pull commits, run validation, and stage internal builds well before a community GA. MySQL commits, per AWS, are available closer to the public release, which compresses the pre-GA validation window. That alone explains why RDS for PostgreSQL minors ship in a week while RDS for MySQL minors get a full month.

Aurora is a different animal. It replaces the community storage engine with a distributed storage layer, and it layers on Global Database and serverless capabilities. Every new engine version has to be re-validated against that substrate. Read replicas, log shipping, crash recovery, and serverless scaling paths all need to keep working. That is why Aurora PostgreSQL takes 3 months for a minor that RDS ships in 7 days, and why Aurora MySQL majors get 12 months versus RDS MySQL's 6.

The <major>.1 anchor is the other piece worth understanding. Postgres 18.0 is not what lands first on AWS. Postgres 18.1 is, roughly three months later, after the initial round of production bugs surface and get patched. If you're familiar with Postgres release notes, you know the .1 usually cleans up meaningful edge cases. AWS is codifying an operational preference many senior DBAs already hold: don't run .0 on anything that pages you at night.

My take: this is AWS admitting that its version cadence has always been a hidden capacity planning input, and finally treating it like one. Publishing the SLA is more useful than shortening it.

Who Gets Burned

The uncomfortable read: teams standardized on Aurora for the "managed everything" pitch are now looking at documented lag times that RDS customers don't wear. If you run Aurora PostgreSQL and a critical CVE lands in a community minor, you are waiting up to 3 months. RDS for PostgreSQL customers are waiting up to 7 days. On a security-sensitive workload, that is not a rounding error.

iGaming platforms feel this most acutely. Regulators in several EU jurisdictions expect timely patching of known vulnerabilities. A 3-month window on Aurora minors means you need a compensating control story ready, or you shift patch-sensitive workloads back toward RDS. Production incidents I've seen involving delayed database patching tend to be found by auditors before they're found by attackers, but both happen.

Fintechs running Aurora MySQL for ledger systems get the harshest number: 12 months for a major version. That is a full annual planning cycle. If Oracle MySQL LTS ships a major with a feature you were counting on for Q1, and you're on Aurora MySQL, you are almost certainly not getting it in Q1. Teams I've worked with tend to underestimate this lag by half.

Ad-tech shops running Aurora for the serverless scaling story should look at LTS. The 12-month LTS-per-major window on Aurora means you can lock in a stable minor and align major upgrades with your own release train, rather than chasing community cadence. That is the correct posture for high-throughput analytics where engine churn causes more pain than missing features.

MariaDB shops, mostly self-hosted refugees moving to RDS, get a clean deal: 30-day minors, 3-month majors from first patch. Nothing to complain about there.

Playbook for Engineering Teams

Do this in the next two weeks.

First, map your current engine versions against the published timelines. Identify every database that is more than one minor behind and calculate when the next community release will realistically appear on AWS. Put those dates on the same calendar as your product roadmap. If your Aurora PostgreSQL fleet is more than two minors behind, that is a governance problem, not a technical one.

Second, turn on automatic minor version upgrades for anything that isn't a Tier 0 revenue system. The 7-day RDS Postgres window is worthless if patches sit ungpplied because nobody wants to own the maintenance window. Pair it with AWS Organizations upgrade rollout policies so dev and test absorb the risk before production.

Third, adopt Blue/Green Deployments as the default path for majors. Cutover with minimal downtime is the difference between a Tuesday afternoon upgrade and a weekend war room. Combine it with OpenTelemetry instrumentation on the application side so you can compare query latency between blue and green before flipping traffic.

Fourth, use RDS Database Preview for major version testing. Getting hands on a new PostgreSQL or MySQL major in a non-production environment before it hits Aurora GA gives your app team months to catch breaking changes in query planners, extension compatibility, and driver behavior.

Fifth, if you are approaching community end-of-life, buy time with Amazon RDS Extended Support and use it. Don't treat it as a permanent home. Treat it as a runway to finish the upgrade you already scheduled.

Key Takeaways

• RDS for PostgreSQL minors ship within 7 days of community release. Aurora PostgreSQL minors take up to 3 months. Plan security patching against the slower number.
• Aurora major versions lag RDS by design because of the distributed storage, Global Database, and serverless layers that need re-validation each release.
• Postgres and MariaDB timelines are measured from the first patch release, not .0. AWS is baking in the "never run dot-zero" instinct as policy.
• Aurora LTS releases within 12 months of Aurora major GA give stability-first teams a documented multi-year baseline. Use it if engine churn hurts more than missing features.
• Turn on automatic minor upgrades, adopt Blue/Green for majors, and use RDS Database Preview and Extended Support as tactical instruments, not permanent fixtures.