Database engines are often the last tier in the estate to be patched, because every update means a restart, a failover or a schema upgrade on the system the business can least afford to lose. The result is predictable: operating systems get patched on a monthly ring, while the database binaries on top of them sit several release updates behind. This guide covers what is specific to patching database engines: each major engine's servicing model, how to plan failover windows for clustered and replicated databases, managed cloud database maintenance, and how to run exceptions without letting them become permanent. It is written for DBAs, platform engineers and vulnerability managers. General patch programme design (SLAs, rings, tooling) is covered in the Patch Management Guide and is not repeated here.
Key takeaways
- Know each engine's servicing vehicle. Oracle ships quarterly Release Updates, SQL Server ships cumulative updates and GDR security updates, PostgreSQL ships minor releases at least every three months, and MySQL splits into LTS and Innovation tracks. Your SLA has to be written against those vehicles.
- Binary patching and data dictionary patching are two steps. Several engines need a post-install step (Oracle datapatch, SQL Server script upgrade mode on first start, PostgreSQL extension updates) that touches the database itself, and that step is where outages and rollbacks get complicated.
- Use the replica you already paid for. Availability groups, Data Guard, RAC and managed Multi-AZ deployments exist so that you can patch a secondary, fail over and patch the old primary. The order matters and is vendor-specified.
- Managed does not mean patched on your terms. Cloud database services apply mandatory updates after a published date whether or not you moved the window, so the maintenance calendar must include provider dates.
- Exceptions need a compensating control and an expiry. A database that cannot take a patch this cycle should get network restriction, account review and monitoring, plus a dated re-review, not an open-ended waiver.
Why database tiers fall behind
Database patching inherits all the usual patch management problems and adds four of its own. Understanding them is the first step to setting realistic targets.
- Downtime is visible and owned by someone else: the application owner has to agree to a window, and the DBA team often cannot schedule one alone.
- Vendor certification lock-in: packaged applications (ERP, core banking, EHR) often certify a specific database release update, so the database team waits for the application vendor.
- Fear of plan regressions: engine updates can include optimiser fixes. Oracle states that its Release Updates contain "security, regression (bug), optimizer, and functional" fixes, which is exactly why some teams hesitate.
- Scanners see it late: many network vulnerability scanners identify the engine version only with authenticated database checks, so unauthenticated scans under-report database exposure.
The exposure is real. The CISA Known Exploited Vulnerabilities catalogue includes database engine flaws such as CVE-2025-14847 in MongoDB Server (added 29 December 2025) and CVE-2019-1068, a SQL Server remote code execution flaw from 2019 that was only added on 26 August 2026, years after the fix shipped. Old database bugs stay useful to attackers because so many instances never receive the fix.
Engine servicing models at a glance
Write your patch standard against the vehicle each vendor actually ships. The table summarises what each vendor's documentation says, checked in November 2026.
| Engine | Security fix vehicle | Cadence (vendor stated) | Post-install step | Vendor guidance |
|---|---|---|---|---|
| Oracle Database 19c and later | Release Update (RU); Monthly Recommended Patch (MRP) on 19c Linux x86-64; Database Critical Security Patch Update (CSPU) from May 2026 | RUs quarterly, third Tuesday of January, April, July and October; MRPs and CSPUs monthly | Run datapatch to apply SQL changes; check DBA_REGISTRY_SQLPATCH | Stay current with RUs; perform all patching out of place (new Oracle home) |
| Microsoft SQL Server 2017 and later | Cumulative update (CU); GDR security update on either the RTM or CU baseline | CUs monthly for the first year, then every two months for the rest of mainstream support; security updates only in extended support | Database scripts run on first service start after update | "Microsoft always recommends that you install the latest CU that's available" |
| PostgreSQL | Minor release (for example 17.10 to 17.11) | At least once every three months, plus out-of-cycle releases for critical fixes | Usually none; some minor releases need extra steps listed in release notes | Always run the current minor release; minor updates need no dump and restore |
| MySQL 8.4 and later | LTS update (fixes only) or Innovation release (features and behaviour changes) | No fixed cadence stated on the release model page | In-place upgrade within an LTS series is supported | Use LTS where stability matters; Innovation suits teams with strong automated testing |
Two consequences follow. First, an Oracle estate that only patches quarterly is now a month or more behind on critical fixes that Oracle ships through the monthly CSPU and MRP vehicles, so decide explicitly which vehicle each tier follows. Second, SQL Server's GDR branch carries security fixes only, which suits systems where change risk is very high, but you cannot move from a CU baseline back to the RTM GDR branch, so choose the branch per instance deliberately.
Support lifecycle drives the hard deadlines
Engine end of support is the most predictable patching cliff. PostgreSQL supports each major version for five years; PostgreSQL 14 reaches its final release on 12 November 2026, and 13 is already unsupported. SQL Server 2016 and earlier no longer receive CUs, and products past extended support need an Extended Security Update subscription to receive security fixes. MySQL LTS series get five years of premier and three years of extended support under Oracle Lifetime Support, while Innovation releases are supported only until the next Innovation release. Track these dates in the same register as your exceptions, because an unsupported engine is an exception that can never close by patching. See End-of-Life Language Runtimes for the same problem one layer up.
Planning failover windows by topology
For any database with a replica, the patch window should be measured as "the length of one failover", not "the length of the install". Vendors document a specific order, and following it is what makes the window short.
| Topology | Vendor-documented pattern | Outage seen by the application | Main trap |
|---|---|---|---|
| SQL Server Always On availability group | Remove automatic failover; patch asynchronous secondaries, then remote synchronous, then local synchronous; fail over manually to a SYNCHRONIZED local secondary; patch the old primary | One manual failover (two if you fail back) | Mixed versions are only supported during the rolling upgrade; readable secondaries stop serving reads mid-upgrade |
| SQL Server failover cluster instance | Patch inactive nodes before active nodes | One failover | Cluster-Aware Updating is not supported for updating availability groups |
| Oracle RAC | Rolling patch node by node (Oracle lists RAC Rolling as the zero-downtime method for RUs and MRPs) | Connections drain per node | Datapatch still runs once against the database; stop Data Pump and GoldenGate first |
| Amazon RDS Multi-AZ | OS updates: standby first, promote, then old primary. Engine upgrades: both modified at once | OS update: failover, typically under a minute. Engine upgrade: both unavailable until complete | Assuming Multi-AZ hides engine upgrades; use Blue/Green Deployments where supported |
| Single instance, no replica | Out-of-place install where the engine supports it, then restart onto the new binaries | Full restart plus any post-install step | No rollback path if the post-install step fails and no backup was verified |
Microsoft's rolling upgrade guidance for availability groups is a useful model for any engine. Before starting it says to perform "a practice manual failover", take a full backup of every availability database and run DBCC CHECKDB, and it warns: "Always fail over the AG to a synchronous-commit secondary replica instance." For disaster recovery replicas that normally run asynchronously, it describes temporarily switching to synchronous commit, waiting for the SYNCHRONIZED state, failing over, then switching back. Clustering itself carries identity and hardening concerns covered in Windows Failover Cluster Security.
Managed cloud databases: whose window is it?
Managed services move the work but not the accountability. Using Amazon RDS as the documented example:
- Maintenance window: a weekly 30-minute window set with PreferredMaintenanceWindow; if you do not set one, RDS picks a random 30 minutes from an eight-hour regional block. Maintenance can run past the end of the window.
- Required versus available: the console shows each update as required, available, next window or in progress. Required updates can be deferred but not indefinitely.
- Mandatory OS updates: these carry a CurrentApplyDate, and AWS warns that repeatedly moving the window does not prevent them; after the date RDS can apply them outside your window.
- Visibility: DescribePendingMaintenanceActions lists what is queued per instance, and the RDS-EVENT-0230 event notifies you when an optional OS security update is available.
Treat provider apply dates as fixed dates in your change calendar and pull them into the vulnerability management system through the provider API. Fully managed tiers such as Oracle Autonomous Database are updated by the provider, so your evidence becomes the provider's attestation and your own version checks. Engine-specific hardening for these platforms is in Amazon RDS and Aurora Security Guide and Azure SQL and Cosmos DB Security Guide.
How to implement a database patching cycle
- Inventory by engine, version and patch level: collect build numbers with authenticated queries (for example SELECT @@VERSION on SQL Server, SHOW server_version on PostgreSQL, DBA_REGISTRY_SQLPATCH on Oracle) rather than relying on host package data, because instances on the same host can differ.
- Set a target per tier: for example, current RU or CU minus one for packaged-application databases, current minor release for PostgreSQL, and emergency handling for anything listed in the CISA KEV catalogue (see the Emergency Out-of-Band Patching Playbook). These targets are NHI Mgmt Group recommendations, not vendor requirements.
- Stage in a production-shaped copy: restore a recent backup to a test instance on the new build and replay a representative workload. Compare query plans for the top statements by resource use, which is where optimiser fixes show up.
- Prepare rollback before the window: verified backup, the previous binaries or Oracle home kept in place (out-of-place patching makes this a path switch), and a written decision point for when to roll back rather than fix forward.
- Quiesce dependent jobs: Oracle instructs that Data Pump jobs are stopped and GoldenGate processes shut down before patching; apply the same idea to replication, ETL and backup jobs on every engine.
- Patch replicas first, then fail over: follow the topology order above, verifying synchronisation state between each step.
- Run and verify the post-install step: datapatch, script upgrade, extension updates. Check the engine's own registry of applied patches, not only the installer exit code.
- Close with evidence: record the new build number, the change ticket, and any exception raised for instances that were skipped.
Pilot the cycle on one non-critical cluster first, then expand by tier. Rollback differs by step: binary patches can usually be reversed by restarting on the old home or uninstalling the CU, while dictionary changes may need the engine's documented rollback mode or a restore, so test the rollback path in staging at least once per engine version.
Decision guidance
- RU only or RU plus monthly vehicles (Oracle): Oracle's default example for single-instance databases is the latest RU each quarter and no MRPs. Move high-exposure tiers to the monthly vehicle when internet-facing applications reach them or when a CSPU addresses a vulnerability you are exposed to.
- CU or GDR branch (SQL Server): the CU branch gets all fixes and is Microsoft's recommendation; the GDR branch suits a small number of tightly certified systems. Pick per instance and record it.
- LTS or Innovation (MySQL): LTS for anything with a long certification cycle; Innovation only where you test continuously, because behaviour changes can affect SQL syntax and query execution.
- Small organisations: prefer managed services with auto minor version upgrade enabled in non-production, and a fixed monthly window in production.
- Large estates: fleet tooling (for example Oracle Fleet Patching and Provisioning, which Oracle recommends for RAC, Data Guard and larger fleets) and gold images per engine version reduce snowflake builds.
Exceptions and compensating controls
Some databases will miss a cycle. The Virtual Patching and Compensating Controls Guide covers the general approach; for databases the useful controls are specific:
| Exception reason | Compensating controls | Maximum review interval (NHI Mgmt Group recommendation) |
|---|---|---|
| Application vendor has not certified the update | Restrict listener ports to application hosts only; disable unused features and extensions; raise a vendor ticket and record its reference | One patch cycle |
| No maintenance window agreed | Escalate to the system owner with the CVE list; database activity monitoring alerts on the vulnerable feature | 30 days |
| Engine version out of support | Network isolation, upgrade project with a date, ESU where offered | Quarterly, with executive sign-off |
| KEV-listed flaw cannot be patched | Remove network reachability or disable the affected component; treat as an incident-level risk acceptance | 7 days |
Where identity fits
Patching needs privilege, and database patching needs a lot of it: OS administrator on the host, a SYSDBA or sysadmin login inside the engine, and often cloud permissions such as ApplyPendingMaintenanceAction. Patch automation accounts are high-value targets because they reach every database. Give them just-in-time elevation, separate credentials per environment, and log their use. Patching is also when service account passwords and stored credentials tend to break, so check linked servers, replication logins and job owners after each cycle. See the Database Credential and Access Security Guide and How to audit SQL Server service accounts and logins.
Detection and measurement
- Patch level coverage: percentage of database instances on the target build for their tier, measured from authenticated version queries.
- Release-to-production time: median days from vendor release (RU, CU, minor release) to production, per engine.
- KEV exposure: count of instances with a KEV-listed flaw open, and days open; the target is zero beyond the emergency SLA.
- Exception health: open exceptions, percentage past their review date, and percentage with a recorded compensating control.
- Window efficiency: actual application-visible outage per patch event against the planned failover time.
- Post-install verification rate: percentage of patch events with a confirmed entry in the engine's patch registry.
Alert on version drift (an instance whose build goes backwards or differs from its replica partner outside a change window) and on new instances that appear without an inventory record.
Framework mapping
| Framework | Reference | How database patching supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation, SI-2(2), SI-2(3) | Remediation within defined time periods, automated status, measured time to remediate |
| NIST SP 800-53 Rev. 5 | CM-3, CM-3(2), CM-4 | Change control, testing and impact analysis of engine updates |
| NIST SP 800-53 Rev. 5 | RA-5, SA-22 | Authenticated scanning of engines; managing unsupported versions |
| NIST CSF 2.0 | ID.RA-01, PR.PS-02, ID.AM-08 | Identify vulnerabilities; maintain and replace software by risk; lifecycle management |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management | Remediation process covering database software |
| ISO/IEC 27001:2022 | A.8.8 Management of technical vulnerabilities; A.8.32 Change management | Vulnerability handling and controlled change |
| MITRE ATT&CK | T1190 Exploit Public-Facing Application; T1210 Exploitation of Remote Services | Techniques that unpatched, reachable database services enable |
Common failure patterns
- Patching binaries but not the dictionary: the installer succeeds, datapatch or the equivalent step is skipped, and the scanner reports the instance as fixed.
- Failing over to an asynchronous replica: Microsoft warns this exposes databases to data loss; always fail over to a synchronised partner.
- Leaving replicas on mixed versions: a half-finished rolling upgrade stops log shipping to unpatched secondaries and quietly removes your disaster recovery copy.
- Trusting host package scans: multiple instances, vendor-bundled engines and container images hide database versions from OS-level inventory.
- Open-ended waivers: "vendor not certified" exceptions that never expire, so the database ages out of support before anyone revisits it.
- Ignoring provider dates: managed instances patched outside the window because the CurrentApplyDate passed, causing an unplanned failover at peak load.
Practitioner checklist
- Record the servicing vehicle and branch (RU, MRP, CSPU, CU, GDR, minor, LTS) for every database instance.
- Collect patch levels with authenticated database queries and reconcile against the CMDB.
- Set per-tier targets and a KEV emergency path for database engines.
- Document the vendor failover order for each topology and rehearse a manual failover before the first window.
- Keep previous binaries in place (out-of-place patching) and a verified backup for every window.
- Stop dependent jobs (replication, Data Pump, GoldenGate, ETL, backups) before patching.
- Verify the post-install step in the engine's patch registry before closing the change.
- Pull managed service maintenance dates into the change calendar through the provider API.
- Give every exception a compensating control, an owner and an expiry date.
- Track end-of-support dates for every engine version and start upgrades a year ahead.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- CISA: Known Exploited Vulnerabilities Catalog
- Oracle: Database Patch Maintenance Guidelines (19c)
- Microsoft Learn: Servicing models for SQL Server
- Microsoft Learn: Upgrading Always On availability group replica instances
- PostgreSQL: Versioning Policy
- MySQL: Release Model (LTS and Innovation)
- AWS: Maintaining a DB instance (Amazon RDS)
Related NHI Mgmt Group resources: Patch Management Guide · NIST SP 800-40 Rev 4 Patch Management Guide · Database Security Guide · PostgreSQL Security Guide · Oracle Database Security Guide