How Fast Do PostgreSQL, MySQL, MariaDB and Valkey Ship Security Fixes?

The short answer

Each project publishes a different kind of promise. PostgreSQL publishes a calendar: a minor release for every supported major on the second Thursday of February, May, August and November, with extra releases when a fix cannot wait. Oracle publishes MySQL security fixes in Critical Patch Updates on the third Tuesday of January, April, July and October, and since May 2026 in Critical Security Patch Updates on the third Tuesday of the other eight months. MariaDB's foundation says it aims to ship binaries with Critical fixes for every supported version, usually within two weeks. Valkey and Redis publish which versions receive security fixes, not when.

None of them publishes an average time from report to fix, and this article does not invent one. What they do publish is enough to plan around: when fixes normally arrive, how long each line keeps receiving them, and what happens when a version falls out of support.

Project by project

PostgreSQL: a calendar, and the willingness to break it

The PostgreSQL project's versioning policy says each major version receives bug and security fixes at least once every three months, and that a critical fix can be released outside the published schedule. It does so in practice. On 21 November 2024 it shipped 17.2 and the matching minors a week after the scheduled November release, and on 20 February 2025 it shipped 17.4 and its companions to fix a libpq regression introduced by the CVE-2025-1094 fix in the scheduled release.

PostgreSQL is also a CVE Numbering Authority. Its security page lists each CVE with the affected majors, the fixed minor version for each, the component (core server, client or contrib module) and the CVSS vector. That table is the most useful single input to a PostgreSQL patch decision, and our own PostgreSQL vulnerabilities by version page builds on it.

MySQL: more advisories, and what they leave out

Oracle's MySQL fixes arrive through Oracle's company-wide advisories. The July 2026 Critical Patch Update contained 54 new security patches for Oracle MySQL, nine of them remotely exploitable without authentication. The June and August 2026 Critical Security Patch Updates added 8 and 9 more. Release dates do not always match the advisory calendar: MySQL 8.4.9 shipped on 21 April 2026, 8.4.10 on 16 June, 8.4.11 on 28 July and 8.4.12 on 18 August. Watch the release notes as well as the advisory dates.

The detail CISOs miss is the column heading. Oracle's risk matrices list "Supported Versions Affected". MySQL 8.0 reached end of life with 8.0.46 in April 2026, and in the July 2026 matrix the MySQL Server rows list 8.4 and 9.x versions only. The advisory therefore cannot tell you whether 8.0 is affected, and no community 8.0 release will fix it. MySQL 8.0 end of life covers the options.

MariaDB, Valkey and Redis

MariaDB's security policy splits bugs into two classes. Critical means arbitrary code execution, or an unauthenticated user crashing the server or reaching data; those are fixed immediately and released for all supported versions, usually within two weeks. Everything else is Medium and waits for the planned release. Note the two-tier support window: after the community binary period ends, critical and security fixes continue for two years as source code only, which means you build the binaries yourself.

Valkey's release page gives three years of patch releases per minor version and five years of security fixes for the last minor of each major, and says it patches only issues it believes are exploitable. Redis's SECURITY.md says security fixes generally go back one major version, lists the lines it supports, and lets users of 7.2 and earlier take fixes made for 7.4 and later under the BSD-3 licence. Neither publishes a target time, so for both your SLA starts when the release appears.

Writing an internal patch SLA around upstream

An internal SLA that says "Critical CVEs patched in N days" hides two clocks. Separate them:

• Time to a fix. From public disclosure to a fixed build you can install. Upstream controls this for supported versions. For end-of-life versions nobody does, unless you have a vendor that ships patched builds.
• Time to deployed. From the fixed build being available to every affected cluster running it. This is the clock you own, and the one auditors test.

Then set the deploy clock by risk, not by CVSS alone. CISA's Binding Operational Directive 26-04, issued on 10 June 2026 for US federal civilian agencies, is a useful public model: it sets timelines from whether the asset is publicly exposed, whether the CVE is in the Known Exploited Vulnerabilities catalog, whether exploitation can be automated and how much control it gives. Its most urgent combination must be fixed within three days, with forensic triage; low-risk findings on assets that are not exposed can wait for the next planned upgrade.

Practical consequences for database estates:

• Pre-book maintenance windows in the week after each PostgreSQL release date and each Oracle advisory date, so scheduled fixes never need an emergency change.
• Keep a tested emergency path, replica first, then switchover, for out-of-cycle releases and Security Alerts.
• Record the component of each CVE. A PostgreSQL client or contrib CVE may not touch the server you run; record why in a VEX statement, as in SBOMs and VEX for database servers.
• List every cluster on an end-of-life line as a standing exception with an owner. Its time-to-fix clock does not stop on its own. The end-of-life tracker has the dates.

Where OSSeva fits

OSSeva closes the time-to-fix gap for lines upstream no longer patches. For PostgreSQL, OSSeva Patch ships quarterly patched releases aligned with the community minor release schedule; for MySQL 5.7 and 8.0, it ships patched builds following each quarterly Oracle Critical Patch Update. On OSSeva Operate the commitment becomes contractual: OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days, alongside 24/7 operations and a 15-minute P1 response. Patch and Assure customers get the builds and the notifications; Operate is the tier that carries the patch SLA. See PostgreSQL, MySQL, MariaDB and Redis and Valkey coverage. Pricing is per cluster; book a discovery call for a quote.

Frequently asked questions

How often does PostgreSQL release security fixes?

At least quarterly, on the second Thursday of February, May, August and November, for every supported major version. Critical fixes can be released between those dates, and the project treats its schedule as a minimum.

When is the next Oracle Critical Patch Update for MySQL?

Oracle lists 20 October 2026, 19 January 2027, 20 April 2027 and 20 July 2027. Critical Security Patch Updates fall on 17 November 2026, 15 December 2026, 16 February 2027 and 16 March 2027.

Do MySQL 8.0 users still get fixes from Oracle's advisories?

Not as community releases. MySQL 8.0 ended with 8.0.46 in April 2026, and Oracle's 2026 risk matrices list supported MySQL Server versions, which for the July 2026 update were 8.4 and 9.x.

What is a reasonable internal patch SLA for databases?

One that measures time from fix availability to deployment, varies by exposure and known exploitation, and treats end-of-life clusters as exceptions with owners. BOD 26-04 is a public model: three days for the most urgent combination, the next upgrade for the least.

Does MariaDB patch security bugs faster than its normal releases?

For Critical bugs, yes: its policy aims to ship fixed binaries for all supported versions usually within two weeks. Medium bugs are fixed in the next planned release.

How long does Valkey support a version?

Three years of patch releases from a minor version's first release, and five years of security fixes for the last minor of each major. Valkey 7.2, first released on 16 April 2024, has maintenance to 16 April 2027 and security support to 16 April 2029.