Updating SQL Server: CUs, GDRs and servicing branches

This page describes the servicing model of SQL Server 2017 and later, on Windows. The build numbers quoted are real and dated 12 September 2026.

CUs and GDRs

Microsoft dropped Service Packs with SQL Server 2017, when it adopted the Modern Servicing Model. Two types of updates remain:

CUs are cumulative: each one contains all the previous ones. You can go straight from RTM to the latest CU without installing the ones in between.

When mainstream support ends, Microsoft stops releasing CUs. The version then receives only GDRs, until the end of extended support:

The two servicing branches

flowchart LR
    RTM["RTM"] --> GDR1["GDR"]
    GDR1 --> GDR2["Next GDR"]
    RTM --> CU1["CU1"]
    CU1 --> CUN["CU2 … CUn"]
    CUN --> CUGDR["CUn + GDR"]
    GDR1 -. "more recent CU + GDR" .-> CUGDR

From RTM onwards, each version splits into two branches:

• the GDR branch, which receives only security fixes and critical fixes;
• the CU branch, which receives those same fixes and all the others.

As soon as you install a CU, the instance moves to the CU branch and stays there. Going back to the GDR branch would mean uninstalling every CU. Nobody has a reason to do so, since the CU branch already contains every security fix.

Moving from the GDR branch to the CU branch is possible, but not with just any CU. The CU you install must contain the security fixes of the GDR already in place, so it must have been released on the same day or later. Take the most recent build of the CU branch. A CU older than the installed GDR is rejected by the installer, with the message “There are no SQL Server instances or shared features that can be updated on this computer”.

I recommend the CU branch. The RTM of a version contains bugs fixed in the first CUs, and an instance that stays on the GDR branch will never receive those fixes.

Reading the build number

The SERVERPROPERTY function returns the build, the CU level and the matching KB article:

-- Version, update level and KB article of the instance
SELECT SERVERPROPERTY('ProductVersion')         AS version,       -- 16.0.4265.3
       SERVERPROPERTY('ProductLevel')           AS product_level, -- RTM
       SERVERPROPERTY('ProductUpdateLevel')     AS cu,            -- CU26
       SERVERPROPERTY('ProductUpdateReference') AS kb,            -- KB5093420
       SERVERPROPERTY('Edition')                AS edition;

ProductLevel stays at RTM on an up-to-date instance: it reports the Service Pack, and there are none any more. The CU level is in ProductUpdateLevel, which is NULL as long as no CU is installed.

The third group of digits in the build tells you the branch. Its value depends on the version:

For 2019, 2022 and 2025, a third group in 4xxx means CUs have been applied. SQL Server 2017 is the exception, with CUs in 3xxx. So read the build against the RTM of its own version.

Installing the highest build of your branch

When a security fix comes out after a CU, Microsoft releases a build for each branch on the same day. This is what was available for SQL Server 2019 on 14 June 2022:

An administrator looking for “the latest CU” the next day installed CU16 and was left without the June fix. According to the Microsoft documentation, a CU whose build number is higher than that of a CU + GDR contains its security fixes. The practical rule is to install the highest build released for your branch, whatever its name.

Limits of the CU number

SQL Server 2019 received its last CU, CU32, on 27 February 2025. The CU branch keeps receiving security fixes, under the same name:

Two instances that both show CU32 in ProductUpdateLevel can be a year and a half apart in security fixes. Compare the full build number.

Withdrawn CUs

CU7 for SQL Server 2019 (15.0.4063.15, 2 September 2020) is marked “Removed” in the SQL Server 2019 build list. It is rare, but it justifies waiting a few days to a few weeks before installing a CU in production, and testing it on a pre-production server first.

Finding the right build

The method:

1. Get the build of the instance with the query above.
2. Open the build list for its version, and find the row for that build.
3. Move up to the most recent build of the same branch.
4. Follow the KB link, which leads to the download page.

The community site is not a Microsoft publication (and it carries a lot of advertising these days). Check the build and the KB on Microsoft Learn before downloading.

Distribution channels

Windows Update only offers SQL Server updates once you opt in to Microsoft Update, which covers Microsoft products other than Windows. On Windows Server 2019 and later, the setting is under Settings > Windows Update > Advanced options > Receive updates for other Microsoft products. Without it, a server that is fully patched on the Windows side has never received a SQL Server fix.

An update received through Microsoft Update installs unattended, updates every SQL Server component and restarts the service. On a production server, enable Microsoft Update to be notified, and choose the installation time yourself: the Configure Automatic Updates Group Policy setting, option Auto download and notify for install, downloads without installing.

New instances and Microsoft Update

The automatic channel of Microsoft Update only offers the CU + GDR version of a security fix to instances that already have a CU. An instance still at RTM receives the GDR version, and moves to the GDR branch without anyone deciding it. WSUS will not bring it back to the CU branch: you have to do it by hand. The details are in Updates to the Microsoft Update detection logic for SQL Server servicing.

So install the latest build of the CU branch right after installing SQL Server, before enabling Microsoft Update.

Applying an update to a standalone instance

Before

1. Take a full backup of every database, system databases included, to a location other than the server. A virtual machine snapshot does not replace a SQL Server backup.
2. Run DBCC CHECKDB on every database.
3. Read the KB page of the update, especially the known issues section.
4. Warn the users and disable the SQL Server Agent jobs.
5. Check disk space: the package weighs around 500 MB to 1 GB, and the installer needs room for its temporary files.
6. Write down the starting build.

During

Run the package as administrator. A CU package contains the updates for every component of the version, but only updates the ones that are installed. If you add a component later, Analysis Services for example, apply the CU again.

The instance is unavailable during the operation. Allow about twenty minutes on a simple instance, restart included. Restart the server if the installer asks for it.

After

-- The build must match the one on the KB page
SELECT SERVERPROPERTY('ProductVersion') AS version,
       SERVERPROPERTY('ProductUpdateLevel') AS cu;

-- Databases that are not online
SELECT name, state_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE';

-- Upgrade script messages in the error log
EXEC sys.xp_readerrorlog 0, 1, N'upgrade';

Then re-enable the Agent jobs and check a real application process.

Restarting the service has side effects worth knowing:

If something goes wrong

A CU is uninstalled from Control Panel > Programs and Features > View installed updates, under the entry for the SQL Server version. The instance goes back to the previous build. On Linux, you roll the mssql-server package back to its previous version. The backup taken before the operation remains the fallback if uninstalling is not enough.

Updating an Always On availability group

On an availability group, you update one replica at a time, with a single manual failover. Microsoft describes the procedure in Upgrade availability group replicas:

1. Back up every database in the group and run DBCC CHECKDB.
2. Set the automated backup preference to the primary replica only, and remove automatic failover from the synchronous-commit replicas.
3. Update the asynchronous-commit secondary replicas, then the remote synchronous-commit secondaries, then the local synchronous-commit secondaries.
4. Check that the target secondary is SYNCHRONIZED, then fail over to it manually.
5. Update the former primary replica.
6. Restore automatic failover and, if you wish, fail back to the original primary replica.

# Node that owns the cluster core resources
Get-ClusterGroup -Name "Cluster Group"

# Move them to the node hosting the primary replica
Move-ClusterGroup -Name "Cluster Group" -Node PRIMARY-NODE

Never update the primary replica first. An updated primary replica can no longer send its transaction log to secondaries still on an earlier version: synchronisation stops, and the databases are exposed to data loss.

-- Synchronisation state of each database, per replica
SELECT ag.name AS availability_group,
       ar.replica_server_name AS replica,
       DB_NAME(drs.database_id) AS database_name,
       drs.synchronization_state_desc AS state
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id
ORDER BY availability_group, replica, database_name;

How often to check

For a server with no particular requirements, a quarterly check is enough:

1. Get the installed build.
2. Compare it with the highest build released for its branch.
3. If the gap is more than two CUs, schedule a maintenance window.

A GDR that fixes a remotely exploitable vulnerability does not wait for the quarter. The KB page of each GDR links to the matching CVE, which lets you judge.

Do

1. Choose the CU branch, unless a vendor constraint says otherwise.
2. Install the highest build of the branch, CU + GDR included.
3. Read the full build number, and ProductUpdateLevel rather than ProductLevel.
4. Enable Microsoft Update or WSUS, while choosing when the installation happens.
5. Take a backup and run DBCC CHECKDB before every update.

Avoid

1. Looking for a Service Pack for SQL Server 2017 or later.
2. Comparing CU numbers to decide which instance is the most up to date.
3. Leaving a new instance at RTM with Microsoft Update enabled.
4. Installing a CU in production on the day it is released.
5. Updating the primary replica of an availability group before its secondaries.