CU vs GDR: Which SQL Server Update Do You Actually Need?

If you've looked at Microsoft's SQL Server update pages lately, you've probably seen two tracks of releases: Cumulative Updates (CUs) and General Distribution Releases (GDRs). Both are called "security updates." Both show up as patches you're supposed to apply. So which one do you actually need?

The answer matters more than most teams realize. Applying the wrong track can leave you on an unsupported path, missing bug fixes, or — in some cases — unable to apply future updates without a full reinstall.

What a Cumulative Update is

A Cumulative Update is exactly what the name suggests: a cumulative package of every fix Microsoft has released for a given SQL Server version since its last major release. CU5 contains everything in CU1, CU2, CU3, and CU4 plus new fixes. You don't need to apply them in sequence — you can jump directly to the latest CU and get all previous fixes.

CUs include security fixes, bug fixes, performance improvements, and occasionally new features backported from newer SQL Server versions. They're released approximately every 8–10 weeks per SQL Server version, and Microsoft maintains a build number sequence that makes it easy to determine exactly where any given instance sits relative to the current release.

Microsoft's official position is that applying CUs is recommended for all production environments. CUs are the primary patching track.

What a GDR is

A General Distribution Release is a security-only update. GDRs contain the minimum necessary fixes to address critical security vulnerabilities — nothing more. No bug fixes, no performance improvements, no backported features. Just the CVE patches that Microsoft considers essential enough to release outside the normal CU cycle.

GDRs are designed for environments where change control is extremely tight and any non-security change requires extensive testing and approval. They give risk-averse organizations a way to apply security patches without accepting the broader surface area of a CU.

In practice, GDRs are most common in financial services, government, and healthcare organizations where regulatory requirements create friction around any software change, even one from Microsoft.

The branching problem

Here's where it gets complicated. CUs and GDRs are not interchangeable, and they branch from different points in the version tree.

When you apply a CU, you're on the CU track. When Microsoft releases a GDR, they release it on two branches: one for systems on the baseline RTM (Release to Manufacturing) build, and one for systems on each active CU. If you're on CU31 and Microsoft releases a security patch, you need the CU31+GDR package — not the base GDR, which patches a different code branch entirely.

Applying the wrong branch is not a hypothetical concern. Installing a base-branch GDR on a system that's already on CU25 will either fail or leave you in an unsupported mixed state. Microsoft's support team has seen this enough times that their patch guidance explicitly warns against it.

Which track is right for your environment

For most SQL Server environments on AWS EC2 — or anywhere — the answer is the CU track. Microsoft recommends CUs, they include security fixes, and staying on the latest CU means you have a clear support path and access to the most complete set of bug fixes.

The GDR-only track makes sense in specific circumstances: you're in an environment where every change requires 6–8 weeks of UAT, your change advisory board won't approve non-security changes more than once a quarter, or you're on a version of SQL Server where the CU branch has reached end-of-life and only GDRs are still being released.

That last case is important. SQL Server 2017's final cumulative update was CU31 — Microsoft stopped releasing new CUs for SQL 2017 in 2024. Any ongoing security patches for SQL 2017 are released as CU31+GDR packages. Similarly, SQL Server 2019 reached its final CU (CU32) in early 2025. If you're running SQL 2017 or 2019, you're not choosing between CU and GDR — the CU is fixed, and Microsoft periodically releases security-only additions layered on top of it.

Reading Microsoft's build page

When you look at the SQL Server build history page for any version, you'll see rows grouped by CU. Each CU has a base build number. GDRs that were released between CUs, or security updates layered on a final CU, appear as separate rows with slightly higher build numbers.

For example, for SQL Server 2022 you might see:

• CU17 — build 16.0.4175.1 — the full cumulative update
• CU16+GDR — build 16.0.4165.4 — security patch on top of CU16 (relevant if you didn't yet apply CU17)
• RTM+GDR — a much lower build number — security patch for systems still on the original release (you should not be here)

The right package is always the highest build on the CU track you're currently on, or the latest CU if you're ready to move forward. The base-branch GDR (RTM+GDR) is almost never the right choice for production systems that have been running for any length of time.

What this means for your patching process

If you're patching SQL Server manually, you need to track this yourself: know which CU each instance is on, find the right package for that branch, and apply it correctly. For five instances, this is manageable. For twenty or fifty, it becomes a spreadsheet problem that eventually produces errors.

Automated patching removes the branch-selection problem. A well-designed SQL Server patch automation system maintains a catalog of the current recommended build for each SQL Server version, knows which build each instance is running, selects the correct installer automatically, and validates the result after installation. You don't need to think about CU vs GDR branching — the system does it.

PatchPilot maintains a continuously updated CU catalog across SQL Server 2016 through 2025 and handles installer selection per instance automatically. Discovery tells you exactly where each instance sits. Compliance tracking shows you which ones are behind and by how much.

Start a free trial and see the compliance state of your entire SQL Server fleet in about 20 minutes.