Home / Databases

DatabasesHow-toIntermediate

Database patching policy: cadence, rings, HA-aware rolling updates and rollback

Set a patching policy for database engines and their operating systems. Covers cadence by severity, test rings, rolling patching for HA clusters, pre-checks, rollback plans and compliance reporting.

Deepak Bhardwaj3 min read

Applies toSQL Server CUs and GDRs, Oracle RUs, PostgreSQL minor releases, MySQL updates; Windows and Linux OS patching

1. Know the release streams

Engine Stream Typical cadence
SQL Server Cumulative Updates (CU); GDR security updates CUs roughly every 1–2 months in mainstream support
Oracle Release Updates (RU) Quarterly (January, April, July, October)
PostgreSQL Minor releases (17.x) Quarterly, plus out-of-cycle security fixes
MySQL Quarterly releases; LTS and Innovation tracks Quarterly
OS Windows (monthly), Linux distributions (continuous) Monthly

2. Policy

Patch type Deadline (Tier 1/2)
Critical security (actively exploited) 7–14 days
Regular security / CU / RU 30–90 days
Major version upgrade Planned project; before end of support

3. Rings

  1. Ring 0: DBA lab, the day of release + 1 week.
  2. Ring 1: dev and test databases. Application teams run their smoke tests.
  3. Ring 2: non-critical production (Tier 3).
  4. Ring 3: Tier 1 and Tier 2 production, in agreed maintenance windows.

4. Pre-checks

  • A recent full backup (or a VM or storage snapshot) taken.
  • HA healthy: all replicas synchronised, no failover in progress.
  • Disk space for installers and logs.
  • Known-issues list for the release reviewed.
  • Rollback plan written down.

5. Rolling patching for HA

SQL Server Always On AG:

  1. Patch the secondary replicas first.
  2. Fail over to a patched secondary (from synchronous commit, no data loss).
  3. Patch the old primary.
  4. Optionally fail back.

PostgreSQL with Patroni: patch the replicas, run patronictl switchover to a patched replica, then patch the old leader.

Oracle RAC: rolling patch with opatchauto one node at a time (most RUs are RAC-rolling installable). Data Guard: use the Standby-First patch apply where supported.

MySQL InnoDB Cluster / Group Replication: patch the secondaries one by one, then switch the primary and patch the old primary.

6. Rollback

Engine Rollback method
SQL Server Uninstall the CU (Programs and Features), or restore from a snapshot
Oracle opatch rollback, plus datapatch
PostgreSQL Install the previous minor package (minor releases don't change the on-disk format)
MySQL Downgrading within a series isn't always supported, so take a snapshot or backup first

7. Reporting

Track the version of every instance in the CMDB or monitoring tool and report compliance monthly (% within policy, a list of exceptions with owners and dates).

SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductUpdateLevel');  -- SQL Server
SELECT version();                                                                -- PostgreSQL
SELECT banner_full FROM v$version;                                               -- Oracle
SELECT @@version;                                                                -- MySQL

Tip

Patch HA clusters a replica at a time and check the AG/cluster dashboard after every step. Most patching outages come from patching the second node while the first is still resynchronising.