Stairway to Transaction Log Management in SQL S erver, Level 2: A Brief Overview of Transaction Log Architecture (2025-05-14)

Evergreen SQL Server

This editorial was originally published on Jul 24, 2019. It is being republished as Steve is traveling today.

Colorado is a beautiful state, one that my family and I have enjoyed many times. We like the summer and winter outdoors, including lots of days skiing. We have plenty of trees on the slopes, which is both great to view and a series of obstacles to avoid. Fortunately, the pines and spruces keep their needles all year round and are easy to spot.

Recently I caught a press release from Microsoft about the Azure SQL Server platform. It was written as support for SQL Server 2008 and R2 comes to an end. Microsoft certainly wants to pressure those customers to upgrade, as there are lots of them out there and this would be quite a bit of revenue. It's been nearly a decade since R2 and over that for SQL Server 2008. There are a few options Microsoft has for you, though the move to an IaaS system in Azure with 3 years of support might be the only feasible one if you need support for some business reason.

There are other options, and the post calls out some of these as evergreen SQL. Both the Managed Instance and Azure SQL Database are listed here, because there's no need to patch or upgrade these platforms. Microsoft handles this for you, though that's not necessarily as simple as you might expect. I don't know how vendors will deal with Microsoft upgrading code, but certainly your in-house applications that might be built with workarounds for the various bugs that people stumble upon need to be prepared to change code if the bugs fix and behavior changes.

I do like the idea of not needing to patch SQL Server and having the code improve and grow. I also like the idea of my code working and not breaking. While Microsoft has noted they don't plan on removing functionality (deprecated just means there's a better way you should use), what about the features that have bugs and the current behavior needs to change? That can be challenging for in-house development teams, but also a hassle for ISVs.

Perhaps this will get ISVs to write code that handles patches and upgrades. Perhaps this means that we won't get stuck on RTM or SP 1 of some old version of SQL Server because a vendor doesn't want to test and certify their system on patched code. Perhaps it also means they'll write the most basic, generic SQL that uses limited features and will work everywhere without them spending any resources verifying their code. I worry the latter more than the former will be the result of evergreen SQL Server.

Do you want a version of SQL Server, as an instance, a database, or some hosted service that you never patch, but Microsoft does? I wonder how many of you look forward to evergreen SQL for your code.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums