There I was, talking about upgrading to SQL Server 2017 at SQL Konferenz last month. Despite the title of the talk, I was not expecting such a question. But there it was: “Is SQL Server 2017 stable enough to use?”
I stopped. I wanted to laugh. And scream. And cry. I know there are no silly questions, but this one was close. I collected my thoughts and asked for clarification.
“Are you asking because Microsoft stopped deploying service packs for SQL Server?”
“Yes, that’s what I want to hear you talk about.”
I thought this to be the real reason for the question. I was already short on time but decided that this was worth a two-minute sermon. I also decided that it was worth blogging about. I suspect others have similar questions about SQL Server 2017 and instead of waiting for them to find me I’m going to share my thoughts here.
A Brief History of Azure SQL Database
The first part of my answer focused on Azure SQL Database. I had two points to make. First, was that for a period of time in 2016, the code base for SQL Database and SQL Server were identical. Since that time, SQL Database has been slightly ahead on features. You can see this today with items like the data classification feature that was in SQL Database before being added to SSMS 17.5 later.
The second part is related to the first. Azure is a huge sandbox for Microsoft to use to test new features. By the time a feature arrives in SQL Server it has been tested against millions of workloads. This has been the case for many years now. Microsoft has talked about features being “cloud-first, but not cloud-only”. That meant they deployed features to Azure as part of their test-driven development methods. In short, customers need not worry about the stability of a feature in SQL Server 2017.
The Modern Servicing Model
The second part of my answer focused on the new service model announced by Microsoft last year. Starting with SQL Server 2017, Microsoft will no longer make service packs available. Historically, customers would wait for SP1 of a product before they would consider it “stable”. The thought was that SP1 would include all the bug fixes found since the RTM version and thus would be more reliable. However, that is an antiquated way of thinking in the DevOps world of Continuous Integration and Continuous Delivery. In that world, you don’t wait for a service pack. Your builds are stable and only need minor fixes.
Starting with SQL Server 2017, Microsoft will release cumulative updates (CUs) and general distribution release (GDRs) as needed. CUs will be delivered once a month for 12 months, and then once a quarter for the next 4 years. That means you will have a total of 28 CUs delivered during the five-year support lifecycle.
What this means is that you should not think of SQL Server 2017 as some piece of brand new technology. Instead, you should think of it as SQL Server 2016 with a bunch of CUs and a handful of new features, all of which has been thoroughly tested against millions of workloads.
Summary
Yes, SQL Server 2017 is stable.
But don’t take my word for it, go try it for yourself. SQL Server 2017 Developer edition is free. Install and see for yourself it is stable enough for your needs.
Well, this is a good question, but believe it or not, you are not answering the question in a fact-based way. But I can offer you this one.
Since SQL Server 2017 RTM release on Oct 2, 2017 and its latest CU4 release on Feb 20, 2018, there are 176 hotfixes released (I count them in each CU and then sum them together).
select 176.0/datediff(day, ‘20171002’, ‘20180220’) = 1.25 bug found/day
Is this stable or not? I do not know.
I may write a blog later to compare sql 2017 vs previous versions and see whether “SQL Server 2017 is really stable”
Thanks for the comment. Also, I did mention “sermon” in the post. Most sermons are more feeling than fact. But the post does contain facts, yes.
I like your approach to collecting data for this question. I’d suggest you also add in a dimension for the severity of the bugs being found. For example, a security bug would be something I consider to make a platform unstable versus a DMV returning slightly incorrect results.
The number of bugs may be a subset of all known bugs reported or found. We may never know the total number, all we know are how many get fixed. What we could be seeing is that Microsoft is able to fix many more bugs today than they did 3 or 5 years ago.
I’d also suggest you research other platforms such as Oracle to compare how well they are doing. And, when you get this done, please share your results!
Thanks
Tom
Often you will find that the bugs fixed also existed in the previous version, or it is a fix to a new feature in this release (and hence you are not affected, as you cannot use this new feature)
Good point, thanks for the comment!