SQL ConstantCare® Population Report: Winter 2022

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 winter 2022 version of our SQL ConstantCare® population report.

Out of 3,679 monitored servers, here’s the version adoption rate:

The big ones:

  • SQL Server 2019: 32% – taking the lead from SQL Server 2016 for the first time!
  • SQL Server 2017: 20%
  • SQL Server 2016: 27%
  • That combo is 79% of the population right there (83% with Azure), and it supports a ton of modern T-SQL, columnstore, etc features, so it’s a fun time to be building apps with T-SQL

Companies are leapfrogging right past SQL Server 2017. I’m going to hazard a guess that SQL Server 2017 came out too quickly after 2016, and didn’t offer enough features to justify upgrades from 2016.

Does that offer us any lessons for SQL Server 2022? Is 2022 going to be a 2017-style release that people just leapfrog over? Well, as I write this, it’s late December 2022, and I’m not seeing the widespread early adoption that I saw for 2019 where people had it in development environments ahead of the release, learning how to use it.

Me personally, one of the most awesome features of 2022 is the ability to fail back and forth between SQL Server and Azure SQL DB Managed Instances. However, that feature is still in limited public preview that requires a signup. Combine that with the fact that both 2022 and Managed Instances have really low adoption rates, and … I just don’t think this feature is going to catch on quickly. (As a blogger/speaker/trainer, that’s useful information, too – I only have so many hours in the day, and I gotta write material for things I think people are actually going to adopt.)

Okay, next up – adoption trends over time. You’re going to be tempted to read something into this chart, but I need to explain something first: we saw a huge drop in Azure SQL DB users for SQL ConstantCare. In the past survey, we had exactly 500 Azure SQL DBs being monitored – and this round, it dropped to just 64. I talked briefly with a couple of the SaaS customers who stopped monitoring their databases, and they both said the same thing: “We’re not going to change the app’s code or indexes based on what you found, so we’re not going to monitor it further.” That’s fair – throwing cloud at it is a perfectly legit strategy. So now, having said that, let’s see the trends:

This quarter’s numbers are a little misleading because it looks like SQL Server 2019 stole Azure’s market share – but now you know why. If I look at pure installation numbers (not as a percentage):

  • We finally have a customer using SQL Server on Linux in production! It’s only one, but … still, I’m excited about that because I can dig into their diagnostic data and figure out which recommendations aren’t relevant for them.
  • Azure SQL DB Managed Instances stayed steady (but it’s still a tiny number relative to the overall population)
  • SQL Server 2019 definitely grew, and every other version went down
  • There are only 6 instances of SQL Server 2022 (and several of those are Development Edition)

The low early adoption rate of 2022 is more interesting to me when I combine it with another number: Availability Groups adoption is 26%, kinda. Of the production SQL Servers that can (2012 & newer, non-Azure, etc), 26% have turned on the Always On Availability Groups feature. Note that I didn’t say 26% of databases are protected, nor 26% of data volume – just 26% of the servers have the feature turned on, period, and that says something because the feature isn’t on by default, and requires a service restart to take effect.  Actual databases protected is way, way less.

One of SQL Server 2022’s flagship features is Managed Instance link, the ability to fail over databases back & forth between your SQL Server 2022 instances and Azure SQL DB Managed Instance. In theory, that’s awesome. In practice, I’ve never seen a concise live demo setting it up, failing it over, and failing it back. The setup part 1 and part 2 doesn’t look terrible, and the failover looks fairly straightforward, but … there are no docs on troubleshooting it. Between the low adoption rates, the complexity of existing AGs, the complexity of cloud networking, and this brand new feature, I’m … not ready to dig into Managed Instance link anytime soon.

I totally appreciate those of y’all who have the guts to try it, though, especially in production. I think that kind of thing is the future of hybrid databases. Looking at the current population numbers, though, it’s a pretty far-off future.

Previous Post
[Video] Office Hours: Ham Pillow Edition
Next Post
[Video] Office Hours: Holiday Speed Round

19 Comments. Leave new

  • I’m probably wrong but wasn’t 2017’s biggest thing – Linux? My clients have 2017 (all Windows), but their non-Azure numbers mirror the above

    • Yeah, and doing machine learning and R in SQL Server if you want to set your licensing money on fire. I never did understand that one.

    • for me 2017 was also dramatically faster nearly across the board on both good queries and bad queries and even allowed some of the legacy CE options to be turned off for vastly more efficient plans. It also got things like scale out ssis and query store first. There were a small number of regressions however compared to 2016, but generally it was much better than 2012 > 2014 or even 2012 > 2016

      2019 still scares the hell out of me, I was close to getting ready to deploy it then they do a feature update this summer on backup compression with potentially massive implications and I don’t trust MS to not do that again at least without waiting a few more months

      • Hmm, no, Query Store came out in 2016, and 2016 also had options to disable the legacy CE.

        • my mistake on query store – we got it in 2017 first, I guess the 2016 was just being held back.

          The point about the legacy CE was I was able to stop using it in many queries in 2017 and get fewer enormous memory grants that weren’t needed

  • As for SQL on Linux we have 14 prod and 6 non-prod running. So far no real issues over the past few years. These aren’t exactly powerhouse systems; fairly small DB’s but they serve their purpose. A few of them are using replication for reporting which has worked fine. The major reason for going with them is the app team; in this case they were all from Linux background; not Windows. Soooo that was the business decision. Luckily no one has decided to go AOG with these; started to but once reviewed and the requirement for other components came up that went out the window so to speak!

  • I’m on 2016 and you are right that 2017 came out too fast. I was looking at 2019 but with 2022 announced and starting to get out there, I’ll skip 2019 as well.

    No major features I need, just keeping current for support and make the Software Assurance we pay for make sense to the CFO.

  • What happened to 2022 Q1 data ?

  • 40ozCoffeeBreakfast
    December 28, 2022 10:07 pm

    Do you think that 2019 jump is big because everyone was retiring their 2012 instances?

    • This is just a hunch, but I bet if a company is conservative enough to run 2012 for a decade, they wouldn’t jump straight to 2019 in most cases.

      • In my dept I jumped from 2012 to 2019 as soon as the application (external) allowed it. The app vendor validated only SQL 2012 for an older version, 2016 for another version and 2019 for the newest, this dictates what we can use for SQL, there is no other reason.

        • John Ballentine III
          January 3, 2023 10:38 pm

          Similar – we’ve been running 2012 because “it just worked”. When we managed to pound in that we needed to upgrade, the business asked “what can we upgrade to and not touch again for multiple years?” So, we’re doing 2019 also. 2016 where application limits us, but so far not seeing a significant amount of them.

  • So, almost 1 of every 5 servers are 2014 (whose Extended Support ends in les than 1.5 years) or less.

    That’s heavy!

  • Mikael, Sweden
    December 29, 2022 8:42 am

    Hmm … when reading Jessicas post I think I will reconsider. We’re on 2012 and the plan was to have a couple of new servers with 2019 up and running by the end of the year. This year that is. But that’s not going to happen. And in a few days 2019 will be four years old.
    We’re going for Std Edition and will emplement AGs.
    And as for Jessica we’re not going for any of the new features.
    Have you that have already tried 2022 out hit any warning lights?

  • Alessandro Natalino
    December 29, 2022 8:50 am


    If MI did not have the hard cap of 100 DBs (due to AG -> worker thread and all that nice stuff) that would surely be everyone’s favorite option for PaaS services.
    Anyways, the future seems brighter: https://feedback.azure.com/d365community/idea/aee5c868-3425-ec11-b6e6-000d3a4f0f84

  • What I learned from SQL 2019 is to wait at least 6 months before even considering a new version. 2022 RTM is not that long on the market, I am not taking any risks and my core app vendor either. There may be others with this mindset too, explaining the lack of early adoption of 2022.


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.