Difference between cumulative update and service pack in SQL Server

Reading Time: 3 minutes

Have you ever wondered what is the difference between a GDR and CU when Microsoft releases a KB article containing new fixes or security updates of any sort? If you have, read on to get a scoop on it and with a couple of tips along the way.

Setting the stage for GDR vs CU

Let’s see what Microsoft says about it:

The General Distribution Release (GDR) and Cumulative Update (CU) designations correspond to the two different servicing options in place for SQL Server baseline releases. A baseline can be either an RTM release or a Service Pack release.

Microsoft

Starting from the latter a baseline for SQL Server can be either the RTM version of your SQL Server i.e. SQL Server 2016 RTM version is 13.0.1601.5 and you can find your by issuing the following T-SQL code against your SQL Server:

SELECT @@VERSION;
 

There are multiple ways to get the version of your SQL, i.e. if you don’t have access to T-SQL you can check the sqlservr.exe in the corresponding \Binn directory of your installation and get the version from there:

You can also use the SERVERPROPERTY() function and get more granular on the version info, but this is not the main focal point of this post. Check the links at the end for further info on this. A basic T-SQL to get this can be:

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition');
 

“Hold on! What do these version numbers stand for in SQL Server?”

Well these numbers are called “build numbers” and are shown in the following table:

OK, now that we’ve got this out of the way, let’s get back to GDR vs CU thing.

GDR updates – cumulatively only contain security updates for the given baseline.

Microsoft

OK, so GDRs is cumulative and it contains only security updates, no new features, no fixes, nothing else but whatever is considered to be a security update.

CU updates – cumulatively contain all functional fixes and security updates for the given baseline.

Microsoft

On the other hand, CUs are also cumulative and contain security updates but also contain functional fixes.

Important to underline here the notion of “baseline”: baseline can be either an RTM release or a Service Pack release. Well, starting from SQL Server 2017 and on, there are no Service Pack releases anymore only RTM and CUs. So, one could start with the RTM and then apply only GDRs or start with RTM and then apply CUs.
In case you have older than SQL Server 2017, then you can also take into consideration the Service Packs as a baseline.

Caution!

When you start clean from a baseline you can apply GDR or CU as it fits your policy or planning. If you want to keep deploying only GDRs, intentionally, then you should not deploy any CU. This change from GDR can happen only ONCE and then you are on the CU-side of things.

Once you go CU there is no turning back
🙂

sqltattoo

How to apply a new KB release from Microsoft

First, you check you instance version and based on the product version you can cross check with the release, that you want to apply, if your instance is supported or it needs to be “baselined” -if possible- to a supported version before moving on.

Let’s say you have SQL Server 2016 SP1 and you want to apply a CVE that Microsoft has released. As of the time of writing, SQL Server 2016 is only supported if you have applied its latest Service Pack, namely SP2.That means if you really need to patch your instance with the CVE then you need to bring your instance to SP2 level and then you are eligible for it.

You should always test the releases from Microsoft before applying any updates to your production SQL Server to make sure that it does not break your solution, that is if you want to keep your job 🙂

Conclusion

If you intentionally want to apply only security updates on your SQL Server instances, stay on GDR releases. If you want to get additional to security updates, new functional fixes, and whatever else the SQL Team is cooking for you, then use CU releases. Do not forget to always test before you deploy to production.

Cheers!