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 2020 version of our SQL ConstantCare® population report.
Out of the 3,650 servers sending in data recently, the most popular version of SQL Server is still 2016. The combination of 2014, 2016, and 2017 make up 74% of market share right now:
On a percentage basis, SQL Server 2008, 2008R2, and 2012 all lost some share this month – but they didn’t lose it to SQL Server 2016 or 2017, both of which actually went down too. They lost it to 2019 and Azure, which went up a combined 5%. 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:
I love that with a year’s worth of data, we’re able to start seeing clear trends.
My thoughts:
- SQL Server 2016 is still the juggernaut, with 1 in 3 instances overall.
- This marks the first quarter where SQL Server 2019 has more adoption than SQL Server 2008R2! That’s awesome. It’s also up to 1/2 of the market share of SQL Server 2012, which doesn’t sound like much, but looking at its speed of growth, I’m hoping to see 2019 beat 2012 by mid-2021.
- Azure SQL DB is getting close to the market share of 2008R2 too, also, which is good. I’m sure Azure SQL DB is underrepresented in these metrics, though, because we haven’t been marketing specifically to Azure SQL DB users.
In last quarter’s survey, I asked readers to respond in the comments why they weren’t adopting Azure SQL DB. They said things like:
- We use cross-database queries, filestream, filetable
- Lack of control over backups, inability to restore your own data
- Lack of feature parity: xp_cmdshell, CLR, Service Broker
- Size challenges, like a 14TB database
- Cost predictability
None of these are permanent showstoppers: it’s all fixable over time as Microsoft continues to invest more in Azure SQL DB. It’s just a question of, “when are they going to ship enough improvements that a good chunk of users will be able to adopt it?”
Right now, we’re in a bit of a holding pattern. Microsoft hasn’t announced much around those above problems recently. However, I gotta think there’s gonna come a point where, BAM, they’re gonna remove several of those barriers, and suddenly companies are going to be much more interested in SQL-as-a-Service instead of SQL-in-a-VM.
As a consultant & trainer, I have to keep my finger on the pulse of the real market (not the marketing market) too. We all have to figure out where the right place is to invest our learning time and which skills to learn: we just can’t afford to pick ’em all up. I look at the calendar for 2021 and ask myself, “Alright, given this adoption curve, what stuff do I want to learn next year? What skills will I need to pick up in the spring that will pay off by the time fall rolls around?”
This is where it gets so tricky: the features just aren’t out yet, and the adoption isn’t there yet either. With those two things in mind, looking at the calendar, I think I can continue to punt on learning Azure SQL DB specifics for another 6-12 months, and focus on where 96% of the market is: good ol’ SQL Server.
That new Babelfish sure does look interesting, though….
17 Comments. Leave new
This Babelfish looks very huge stuff… Wonder if Microsoft will try to block it.
Huge change to re-learn everything… postgresql firstaidkit???
You have a typo
SQL Server 2026
Hahaha, thanks, good catch. Fixed.
Interesting stuff. Nice to know i’m not the plump one limping at the back of the herd.
You ask yourself what you could focus on. Maybe you could focus on the shortcomings and potential workarounds for SQL Azure? I’m in that camp. I rely heavily on Cross db joins and Db Email. what are my options?
Alternatively you could double down on “not Azure”. As much as it’s exciting to look at shiny things, I work for a small govt org that has zip budget. I’m always looking for ways of getting things done for cheap/free. Hence i’m a long time user of sp_Blitz and Ola Hallengren’s scripts. And for both I am extremely grateful.
Great data! Can you tell from your data if any of these are RDS for SQL Server managed instances?
Alan – I’m not breaking those out separately, no.
Are you tracking Azure SQL Database vs. Azure SQL Managed Instance? The latter has a possible answer to the cross-database query issue with the former.
Mark – read ‘er again a little slower this time. 😉 Check the graphs.
I don’t get the unsupported Azure cross query part (I am not able to try it),
but it seems it is there in :
https://azure.microsoft.com/hu-hu/blog/querying-remote-databases-in-azure-sql-db/
You have to set that up for every database, every table that you want to query, in advance. That simply doesn’t work in the real world.
We also discovered that elastic query doesn’t work with the “private endpoint” feature. In all if my Azure SQL migrations we refactor for multi schema single database which isn’t as bad as it sounds. (Logically, Oracle has worked this way forever right)
That refactor sounds a pretty big workaround just for this. As Brent said, it might change in the near future. Thankfully we can easily split our data up by customers, so we can horizontally scale, worry less about race condition, easy migration from host to host, quick backups, maintenance, etc.
Actually for Oracle, it is not strange anymore to move to multi database world.
It was a thing in the past imho 🙂
Both cross-db queries and db mail are supported in Azure SQL Managed Instance, which is in general focused on minimizing feature gap to SQL Server.
Almost 100% of the software development our company does is backed by Azure SQL DB and not an on-premises SQL Server. That metric is for our software development department and not our SQL Server DBA managed services. We do not have any clients that have engaged our DBA managed services for Azure SQL DB directly. It might be that they believe Azure SQL DB does not need management perhaps. After our software developers deploy and the customer engages in our continuous development services, they also receive some of our managed DBA services.
Like Brent’s client base, our DBA department is not normally engaged until they have problems. We use Brent’s Consultant Toolkit to assess their issues with a SQL Server health check. That can lead to Dba managed services when clients determine their most important business asset is not being properly being taken care of. These have been 100% on-premises SQL Servers. SQL 2016-2017 is the most popular for our clients also.
There are so many benefits to having a DBA taking care of Azure SQL databases. When it comes to keeping DTU usage under control and being able to save a business cash by either moving down a pricing tier or by not upping the pricing tier. It is easy to point to the cost savings and justify the work you perform.
Thanks.
Kevin Martin from https://www.emergentsoftware.net
Azure SQL Managed Instance is interesting to us and we’re looking to move to that in 2021. We started several months ago testing Availability Groups and ran into lots of gotchas in our environment. Having built in ha/dr and evergreen OS/SQL with better RPO and RTO than we could provide locally looks like a far better way to go. We’ll see as we get into testing managed instance.
I would be very interested to hear usage stats on Snapshot Isolation, Query Store, and Hekaton.
“Curious minds want to know.”
Brian – I wrote about Query Store a couple of years ago here, and the numbers haven’t changed much: https://www.brentozar.com/archive/2018/06/building-sql-constantcare-why-people-arent-using-query-store/