It’s Been 6 Months. SQL Server 2022 Still Isn’t Ready Yet. (Updated)

SQL Server 2022
23 Comments

Six months ago today, Microsoft announced that SQL Server 2022 was ready.

Except it wasn’t.

And it still isn’t ready.

See, look at the very first hero in their list of 2022’s new features:

The very first one is “Business continuity through Azure – Bidirectional DR to Azure SQL.” However, buried way down in the footnotes, Microsoft admitted:

The bidirectional disaster recovery capability of the Link feature for Azure SQL Managed Instance is available in limited public preview. Sign up for early access. General availability will occur at a future date.

Well, it’s been 6 months now, and that feature is still only in limited “public” preview, and by “public” I mean you have to apply through a form so the product group can onboard you. The form has some interesting questions that insinuate this thing still needs some baking, like asking how much time per week that you can work with the product group, and asks you to assess your skills:

And at the end of the form:

I applied on April 26th out of curiosity. I haven’t heard a word back.

You might say, “Well, that’s just one of the features – the rest are ready, right?” I’d disagree – the second hero feature was Azure Synapse Link, and the list of current limitations for that is horrific.

  • The table can’t use CDC, Always Encrypted, columnstore, etc
  • The database can’t have transactional replication
  • The database can’t be involved in Azure SQL Managed Instance Link – meaning the very first two hero features can’t even work together

Should you install SQL Server 2022? I think as long as you stay clear of the new features, you’re fine. The new version gets you query performance improvements (especially for Enterprise Edition users) and longer supportability.

But if you want to use these new features, SQL Server 2022 just still isn’t ready.

So next week at Microsoft Build, when you hear folks making grand announcements of upcoming features, just remember that they still haven’t delivered on last year’s “released” features! Take announcements with a grain of salt: until it’s actually in your hands, it’s vaporware. It bums me out to have to say that out loud, but here we are.

Update 2022-05-17: another not-done feature

A reader pointed out to me that Query Store on readable replicas was supposed to be a SQL Server 2022 feature, and that one’s still not done yet after 6 months, either, as the documentation points out:

Previous Post
How to Configure Ola Hallengren’s Database Maintenance Scripts for Backups
Next Post
[Video] Office Hours: 45 Minutes of SQL Server Q&A

23 Comments. Leave new

  • YIKES!

    Reply
  • I’m having significant issues with SQL Server 2022 Enterprise and Query Store in an Always On Availability Group cluster. We literally had to disable Query Store to prevent recurring memory dumps and access violations. MS Support is stumped and my team is frustrated that we went live on this and now have taken a step back in functionality. Hoping that CU4 might address some of it…

    Reply
  • Use it since a few month in prod (Enterprise, on premise, stand alone no AG / HA etc.), primary because of the new T-SQL-features as LEAST(), GREATEST(), DATETRUNC() etc., which works well

    Reply
    • Cool – so are you using the two major new features I talk about in the post?

      Reply
      • No, but the more important features :-), because they make the life easier. But of course you are right, my comment is a little bit off topic, if you focus only onto those two major features, but your caption says, that SQL 2022 is not ready yet, which is only true for those two features, while other new stuff is working fine.

        The major features (if they would working) are edge cases that may be nice / very useful in some environments, while the new T-SQL features may be very basic but can be used by everyone without much effort and are helping immediate.

        Of course nobody would spend 7.5k USD per Core on some new T-SQL-Keywords, but with Software Assurance it is already covered and when you are going to buy / set up a complete new server, you have to buy the most recent version too (but may downgrade it).

        Reply
        • Bingo – like I repeatedly mention through the post, we’re not talking about T-SQL features. We’re talking about the two main features that Microsoft marketing touted as the biggest reasons to get SQL Server 2022.

          Reply
  • Javier Villegas
    May 16, 2023 6:12 pm

    Hi Brent, I agree on the fact that MI link for DR is not fully ready as well as the QDS on replicas mentioned here, but in regards to the Synapse link limitations , even if I agree that are quite a lot, the feature is on V1 and it it doing what they said it will do. I do remember the first version of OLTP in-memory and also were a lot, but they did remove some of those in upcoming mayor versions

    Reply
    • I would not call a feature ready if it won’t work with Change Data Capture, Temporal history table, Always encrypted, In-Memory OLTP, Column Store Index, and Graph. That’s directly word-for-word from the Synapse Link limitations, typos included. (Even the documentation is chock full of typos.)

      Reply
  • matthew.olson
    May 16, 2023 8:36 pm

    That’s frustrating. Those features are literally the thing our management was waiting for and I’m having to tell them “its not ready yet” — I think they are understandably upset because we are about to have a need to stand up some more availability groups and they don’t want to use 2019 and lose out on the extra few years of support, meaning that we’ll have to revisit these servers sooner than we should. So I’m stuck having to either accept the hobbled limitations and reconfigure everything in the future when the features are actually usable, or try to convince management to wait.

    Reply
    • Andrew Snodgrass
      May 17, 2023 12:46 pm

      Matthew, can you not just install 2022 and use as is for your new Availability Groups. And then later, through CUs, start using the Azure-connected features?
      I agree with Brent, some of the new stuff is still half-baked and shouldn’t be put into production.

      Reply
  • Francesco Mantovani
    May 16, 2023 9:44 pm

    It has one hero feature: The database can’t have transactional replication

    Reply
  • Geoffrey Langdon
    May 17, 2023 6:49 am

    We see the same thing with computer games which are released and wont work without one or more large patches – we didn’t get this (as often!) when games were released on floppy disks and online patches weren’t an option – though we do get better games / more features now. Maybe it’s a trade off of more features in exchange for more patches and bugs for both PC games and business critical software?

    Reply
  • Andrew Snodgrass
    May 17, 2023 12:59 pm

    Synapse Link is a funny one for me. It’s supposed to grab a SQL Server table and replicate that table to Synapse. But if I understand it correctly, it doesn’t go directly into a SQL Dedicated pool (which would be compatible) with SQL Server. Instead, there’s a landing zone in Data Lake Storage where the data is stored before being copied to a SQL Dedicated pool. To me, that sounds like it’s being push to a SQL Serverless pool first, which is actually an Apache SQL table. That’s where I believe the incompatibility fallse. The underlying Apache SQL table can only store and work with tech that it understands, which is outside of the AlwaysEncrypted, CDC, In-Memory, etc… capabilities.

    While we’re at it, I would also add all the unsupported data types: image, text, xml, timestamp, and others.
    And the limitation of primary keys and number of columns.

    Personally, if Synapse is my tool, then I’d consider data virtualization or just using CDC directly with a SQL Dedicated pool and bypass the whole Synapse LInk setup. It’s a bit more old-school, but it’s not ETL and it works.

    I know, it’s not what we were promised, but Managed Instance Link for bi-directional DR is still out a ways and HA isn’t ever going to arrive.

    Reply
  • Gordon Feeney
    May 17, 2023 4:20 pm

    It was generally the case a while back, with any new version of SQL Server, that you would wait for at least 6 months after release before installing it in a production environment as that gave plenty of time for major bugs to be identified and ironed out with the first couple of patches. I rather thought that this had improved, however 2022 looks like a retrograde step, particularly for ‘features’ that purport to be available but aren’t, or at least not fully.

    Reply
  • Since trying it with CU4 it logs job successes as failures in the agent log, and changed/broke some important latency columns on AG DMVs. And more.

    They’re minor issues, but which require redesigns out of the box. For large customers who rely on stability it’s not a good look.

    Reply
  • Kinda surprised MS hasn’t piped in yet on this post 😀

    Reply

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.