Ever wonder how fast people are adopting new versions of SQL Server, or what’s “normal” out there for SQL Server adoption rates, hardware sizes, or numbers of databases? Let’s find out in the summer 2022 version of our SQL ConstantCare® population report.
Out of the 3,151 servers sending in data recently, the most popular version of SQL Server is still 2016:
This will be the last version of the report where I’ll break out 2008, 2008 R2, and 2012 separately. Going forward, I’ll just lump ’em under “2012 & Prior” since they’ll add up to even less the next time I do the report.
Mainstream support is over for SQL Server 2014 & 2016, so here’s a number that makes me a little nervous: only 55% of servers are under mainstream support. When SQL Server 2017’s mainstream support ends on October 22, that means only the 23% of users on SQL Server 2019, and the 13% in Azure SQL DB, will be getting regular updates. Yowza.
SQL Server 2016, 2017, and 2019 account for 69% of the user population, and Azure SQL DB took a big jump from about 1% up to about 11%.
Up in the cloud, Azure SQL DB jumped dramatically from 1% overall to about 13%, with 11% of that being Azure SQL DB itself, and Managed Instances at 2% of the population.
The newer products are at the top of this chart, and the new data’s at the right, so you can see the new stuff gradually pushing down the old stuff over time:
While the most popular version is still SQL Server 2016, this year 2019 is getting a lot closer. Every single version’s going down except SQL Server 2019 and Azure SQL DB.
These numbers help to give me perspective when I think about new adoptions of SQL Server 2022. It’s possible that SQL Server 2022 will gain adoption faster than 2019 did because I don’t think there were a whole lot of “I absolutely gotta have that” features in 2019. With 2022’s Availability Groups being able to fail back & forth to the cloud, if that ships in a solid, reliable, easy-to-troubleshoot way, that could be the killer feature that really spurs 2022 adoption.
11 Comments. Leave new
There was a bug with SQL Broker in SQL 2019. It only has been fixed recently by Microsoft. The good news is I’m finally in the process of switching all my production servers from SQL 2016 to SQL 2019!
Hi Brent. Thanks for sharing the great data.
Do you track the platform for IaaS instances hosted in the cloud? i.e. Azure/AWS/GCP/ALI… 🙂
How would you suggest that we do that?
I can’t find a DMV with the info but this could give you an idea. Customers might be horrified though :/)
EXEC sp_readerrorlog 0, 1, N’Manufacturer’;
/*
System Manufacturer: ‘Microsoft Corporation’, System Model: ‘Virtual Machine’.
System Manufacturer: ‘Google’, System Model: ‘Google Compute Engine’.
System Manufacturer: ‘Amazon EC2’, System Model: ‘m5.xlarge’.
*/
I don’t think that produces accurate results since folks can use AWS Outposts and Azure Stack, though.
Yeah, and VMWare Cloud on AWS/Azure too… Grabbing some extra data from the OS might help making a more accurate assessment. This is an interesting problem. I’ll figure it out and report back!
Still on 2016 but the next upgrade will be into the cloud somewhere. $8k or $16k (standard) for licensing plus server costs for a single server without redundancy is a lot of azure sql db time for an app I have the container hosting costs down to $40 a month for 3 AZ redundancy (could run on a single container but business wants redundancy, AWS Fargate makes that easy and cheap for low resource containers).
@Danielle, what was the service broker issue that Microsoft fixed?
As I just ran a project to replace 2012 with 2016 or 2019 (based on app compatibility) for the past 1.5 years, I feel for the people that are still on 2008 to 2014. In some cases the switch is a matter of money, in others a matter of volume, but most of the time it is also a matter of priority for the decision makers.
The second chart is extremely misleading. It goes by quarter for 2020, then jumps to 2021 Q2 and finally to 2022 Q3. It makes it look like there was sudden adoption during the last two periods. But the last period is over four times longer than the first four.
Yeah, I wish I had enough time to produce the chart every quarter, but there were some pretty big things over the last couple of years that threw a wrench in my schedule. Hope you can understand, and hope you still find value in the data overall. Cheers!