Patching SQL Server: cumulative updates, GDR and the order for availability groups

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

SQL Server is not patched like Windows. Its updates come on two branches, arrive on their own schedule, and on a server with an availability group they must be applied in a set order. Getting the branch or the order wrong can mean missed fixes, longer downtime, or a failover that loses data.

This article explains the servicing model Microsoft publishes and the rolling update order for availability groups.

Why it matters

A database server left unpatched misses security fixes. A database server patched carelessly can be down for longer than planned. For a hosted business application, the update plan should say which branch the server follows, how often it is updated, who tests first, and in what order servers are updated.

How it works

Two branches: CU and GDR

Microsoft ships SQL Server fixes in several forms. For SQL Server 2017 and later, two matter for routine patching.

Cumulative updates (CUs) contain All the fixes, improvements, and feature enhancements since the release version of the product. Microsoft states the schedule as Every month for the first year after a SQL Server release, and every two months for the remaining four years of the full 5-year mainstream lifecycle. Microsoft's servicing page notes that CU31 was the last CU for SQL Server 2017, after which only on-demand fixes and security updates ship.

General distribution releases (GDRs) are narrower. Microsoft describes a GDR as addressing an issue that has a broad customer impact, security implications, or both. A GDR cannot be requested by a customer, and Microsoft says the number is kept to a minimum. GDRs are released through the download centre and through Microsoft Update, Windows Update, or both.

A GDR belongs to a baseline

A GDR is built on one of two baselines: the original release (RTM) or a cumulative update. A server that has only ever had GDRs stays on the RTM-GDR line and receives security and selected broad-impact fixes without the full set of changes CUs bring. A server that has a CU installed receives GDRs built for that CU, labelled CU-number-GDR in Microsoft's builds list.

Microsoft also notes that a later CU includes the earlier CU-GDR fixes, and states: Microsoft always recommends that you install the latest CU that's available for a given SQL Server version.

Microsoft's Latest updates and version history page lists, for each supported version, the latest GDR, the latest CU and the latest CU with GDR. Check it for the current builds rather than relying on a number in any article.

Which branch to follow

The trade is between less change and more fixes. Microsoft recommends CUs. Some application vendors certify specific SQL Server builds; check the vendor's requirements before choosing the branch, and record the decision.

Patching an availability group without long downtime

Microsoft describes secondary-first rolling maintenance to reduce primary downtime. The outline below is planning guidance for a qualified database administrator, not an execution runbook. It has not been lab tested for your topology. Before production use, rehearse the exact supported topology, release-specific patch prerequisites, backup arrangements, application reconnection and planned failover on authorised isolated test servers.

1. Establish readiness. Record replica health, synchronisation, a verified recovery plan and the maintenance owner. The plan must include current backups and database consistency checks.
2. Plan failover settings. Microsoft's procedure removes automatic failover from synchronous replicas during maintenance. Record the original settings and the checks required before restoring them.
3. Plan secondaries first. Microsoft's replica maintenance guidance puts remote secondaries before local secondaries, and the primary last. Account for the temporary loss of each secondary's failover/read capacity and its catch-up time.
4. Require a ready planned-failover target. The updated target must be healthy, configured for synchronous commit and synchronised, with the applicable cluster and failover prerequisites satisfied. If these conditions are unavailable, stop or defer the maintenance. Do not substitute a forced failover.
5. Complete and verify the remaining nodes. After an authorised planned failover, the former primary can be maintained as a secondary. Verify synchronisation, backups and application behaviour before reinstating settings or any planned failback.

Do not confuse routine CU/GDR servicing with a major-version upgrade. The source's warning that a newer-version primary cannot ship logs to an older-version secondary concerns database-version incompatibility; it is not evidence that every temporary CU mismatch stops log transport. Check the selected patch's own prerequisites and known issues.

Microsoft also distinguishes backup behaviour: no backup runs on a database while it is being upgraded. Major-version upgrades restrict readable-secondary and backup availability differently from nonversion updates. For nonversion maintenance, its guidance allows secondary backup preference before the primary update. The DBA must plan and rehearse backup continuity for the actual update and topology.

Servers without an availability group

A single SQL Server has no rolling option. The service restarts during the update, so the application is down for that time. Schedule a maintenance window and tell users.

What to choose and why

• Choose the branch deliberately. CUs carry Microsoft's recommendation and all fixes; RTM-GDR carries less change. Record which one each server follows.
• Test each update first on an isolated test server with synthetic or masked data, running the application's own key tasks.
• Patch on a schedule. CUs arrive every one or two months depending on the version's age; security GDRs arrive when Microsoft issues them.
• For availability groups, use a DBA-approved, rehearsed maintenance plan. Secondaries first; proceed with planned failover only when readiness checks pass, then maintain the former primary.
• Patch Windows and SQL Server in planned windows. Both can need restarts.

Risks and limits

• Back up before every update. An update is a change; have a tested way back.
• Stop or defer if planned failover is not safe. Forced failover with possible data loss belongs in a separate, explicitly authorised specialist recovery plan; it is not an alternative step in routine patching.
• Version upgrades are different. Moving to a new major version has more steps and limits than a CU. This article covers CU and GDR updates.
• Clusters are not covered. Failover cluster instance patching and Windows cluster upgrades follow their own procedures.
• No commands are given here. Microsoft's pages describe the steps in detail.

Sources

Opened 14 November 2026.

• Microsoft Learn: Servicing models for SQL Server, source updated 2025-04-08.
• Microsoft Learn: Latest updates and version history for SQL Server, source revision date unavailable.
• Microsoft Learn: Upgrade availability group replicas, source updated 2026-07-20.

Related service: Managed support.

Related future topics

• SQL Server support dates for hosted applications.
• High availability on SQL Server Standard edition.
• Patching hosted Windows applications.

Learning notes

• CUs contain all fixes; GDRs contain security and broad-impact fixes only.
• A GDR belongs to a baseline: RTM or a specific CU.
• Microsoft recommends the latest CU.
• Rehearse the exact AG maintenance plan; stop if a healthy synchronised synchronous target is unavailable.
• Back up and run consistency checks before starting.

This article was originally published on 14 November 2026.