Joey on SQL Server

SQL Server vNext: When and What Is Coming

Ahead of Microsoft Build (and a possible SQL Server announcement), let's break down what we know and speculate about what we don't.

• By Joey D'Antoni
• 05/15/2024

One topic that has come up in several conversations with customers is when the next version of SQL Server will be released. As I always tell customers, even if I knew that, I couldn't tell you (Microsoft MVPs are under non-disclosure agreements with Microsoft about confidential information). So, everything in this column is information I've surmised from looking at what's been going on with Azure SQL Database, which is the most common testing ground for new features, along with some of the enhancements to SQL Server that have come in the cumulative updates Microsoft has released for SQL Server 2022.

The history of release cycles with SQL Server is fascinating. If we go back to the year 2000, the impact of the SQL Slammer virus delayed the release of the much-needed 2005 release of SQL Server, which introduced a myriad of internal enhancements and provided much of the foundation for future releases of the product. From 2005, we saw a three-year release cycle to 2008, followed by the poorly named SQL Server 2008 R2 in 2010, which mostly saw improvements to the business intelligence stack and not the core engine.

One of the primary drivers of this rapid release cadence, which continued through SQL Server 2019, was the demand of Software Assurance (SA) customers to get value for their investment. With SQL Server 2022, there was a shift back to a slightly slower cadence, which we are back to -- I'm not expecting a SQL Server 2024, but you never know.

Microsoft has leveraged its cloud database for new features in the past, but there is no inherent guarantee that features will be released there first. In most cases, they are, but sometimes, a feature misses a build cycle and doesn't make it into the cloud for a while. As I recall, the scalar function inlining query optimization improvement, made it to GA in SQL Server 2019 before it made it to Azure SQL DB. However, a couple of exceptions aside, looking to the PaaS offerings is a good approach, as the frequent release cycles.

Looking back through the new feature updates for Azure SQL DB, you see several clear trends. One reasonably obvious is the number of AI-related features. Given that those features have heavy dependencies on GPUs running in Azure, I expect that any AI features would be relegated strictly to Azure or at least to on-premises servers running Azure Arc for SQL Server. The complexity of implementing these features means they will likely remain partially in the cloud for a long time.

There are a few features I'd like to talk about, both of which are related to development. The first is support for regular expressions, which has long been a feature gap between Oracle and SQL Server. If you aren't familiar with the dark arts of RegEx, it's a powerful tool for pattern matching, searching, and manipulating text data flexibly. Given that this is "just" a language feature (meaning the code driving the feature is likely entirely contained within the database engine), this is something that I would expect to see when the next version of SQL Server arrives.

Another feature that quietly arrived in Azure SQL Database is "optimized locking." If you aren't familiar with the ACID properties of relational databases, specifically the "C" for consistency is handled by a set of latches and locking structures that exist in the memory of the database engine's process to manage concurrency between user sessions that are reading, inserting and updating data into a table. To summarize the difference between the way SQL Server has traditionally taken locks and optimized locking, I'll defer to my MVP colleague Aaron Bertrand, who, in his post on the topic, said, "Instead of locking individual rows and pages for the life of the transaction, a single lock is held at the transaction level, and row and lock pages are taken and released as needed."

This behavior is built on top of another recent feature, Accelerated Database Recovery, which has a persistent version store. This allows the database engine to evaluate against the last committed version of a record, bypassing the need for a lock until it is ready to update. This is a very simplified explanation, and this academic paper on ADR makes some reference to it, which provides some brief detail.

While SQL Server introduced support for JSON data in SQL Server 2016, it relied on using the non-optimized NVARCHAR(MAX) data type. While it worked, the functionality was limited, and performance was challenging. Last year, Microsoft introduced a private preview of a new JSON datatype and a handful of additional functions to aggregate tabular data into a JSON document. Ideally, this data type would come with some dedicated indexing structures, the way SQL Server has XML indexes, allowing faster queries against large volumes of JSON data.

One of the challenges Microsoft faces is that it can be tough to upgrade SQL Server versions within organizations. Even though Microsoft has changed its support policies to support upgrades better, software vendors and large enterprises still need help to upgrade to new releases. Understandably, databases are core infrastructure components that drive essential applications so that a conservative approach can be helpful. One exciting thing about Azure SQL DB is that the releases have minimal impact on your application as features get added. Still, either aren't turned on unless you code your application to use them or have no direct application impact. This behavior of PaaS databases makes me think, what if we didn't have versions of SQL Server and just got updates? What do you think?

Onto our final question: when will the next version of SQL Server be released? Microsoft typically announces things at significant conferences, and with both Ignite and PASS Summit (a Microsoft data platform-specific conference), I believe Microsoft will likely announce a preview version of SQL Server. No promises -- this is purely my speculation, but given the recent feature waves in Azure SQL DB and the timing since SQL Server 2022's release makes, this a safer bet.