Starting with yesterday’s release of SQL Server 2017, Microsoft has a new servicing model: they’re only delivering Cumulative Updates, and not doing Service Packs.
- SPs will no longer be made available. Only CUs, and GDRs when needed.
- CUs will be delivered more often at first and then less frequently. Every month for the first 12 months, and every quarter for the remainder 4 years of the full 5-year mainstream lifecycle.
- CUs are delivered on the same week of the month: week of 3rd Tuesday.
I adore this change for a few reasons:
- It makes patching simpler – no more trying to figure out which CU branch you’re supposed to be on
- It makes scheduling easier – if you take, say, quarterly outages, then you can just apply the most recent CU available based on your downtime schedule
- It removes the “wait until SP1” stigma – there’s a good chunk of the population that thinks a product isn’t ready until the first major update, and now maybe they’ll see the first monthly CU1 as that adoption point.
This will influence how people see versions.
Examine this sentence closely:
“Every month for the first 12 months, and every quarter for the remainder 4 years…”
That means in November 2017 – October 2018, SQL Server 2017 is going to get monthly patches. However, starting in November 2018, it’s going to be more stable.
So now fast forward to late 2018, early 2019. You’re about to build a new SQL Server for a project, and you have two choices:
- SQL Server 2018 – which is basically the new dev branch, getting monthly updates, or
- SQL Server 2017 (or 2016, or 2014) – which is the stable branch, getting quarterly updates
Once a version has hit CU12, and it only gets updates once a quarter, it might be considered Good Enough For Our Apps. Managers might see 2017/2016/2014 interchangeably at that point – which might be great for the second most recent version’s adoption.
CU 12 might be the new SP1.
I can see managers saying, “Well, I don’t wanna go to a new version of SQL Server until they’ve eased up on the fast-and-furious update stream. I can’t take an outage every month to apply patches. Plus, based on the looks of some of these bugs they’re fixing, the software’s not really ready for prime time yet.”
And I wouldn’t blame them. After all, check out just some of the highlights from the most recent Cumulative Update, 2016 SP1 CU5:
- Stack dumps when you query a DMV
- Also, when you query this DMV
- Stack dumps when you query a clustered columnstore index where “the data pages are too far apart” (whatever the hell that means)
- Wrong query results with memory-optimized table variables
- Availability Groups automatic seeding randomly fails
- Errors when you resume a suspended Availability Group database
- Crashes due to spinlock contention
- Managed backups…don’t
And remember, this isn’t the fifth Cumulative Update for 2016: it’s the fifth update FOR 2016 SERVICE PACK 1. If you deployed SQL Server 2016 in June 2016 when it came out, you’d have had 8 patching outages by now to fix stuff like this.
Which is fine: adoption is slow anyway.
In the company chat room, Tara pointed out that few people jump on the most recent release anyway. SpotlightEssentials reports that <10% of servers are using SQL Server 2016 even today. That means ~90% of servers would be on the stable branch, getting CUs only once per quarter.
Years from now, I think we’ll all be glad that Microsoft took this step and switched to a simpler servicing model. There’s going to be a few pains as we explain to managers that no, you don’t need to wait for SP1 anymore – but depending on your stability goals and patch windows, you might wanna wait for CU12. (However, 90% of you aren’t installing the new version in the first 12 months anyway – so you’re unaffected.)