Joey on SQL Server

SQL Server 2016 Changed the Database World -- Now Its Final Countdown Has Begun

As SQL Server 2016 approaches end of support in July 2026, a look back at its groundbreaking innovations reveals how it reshaped Microsoft's data platform and why it's time to move forward.

• By Joey D'Antoni
• 05/12/2026

As I've gotten older, one of the surprising revelations of age is how much faster your perception of time is. When I was very young, waiting two weeks for another bike race seemed like an eternity. Now that I'm older, it feels like ten years can pass in the blink of an eye. Which brings us to the main topic of this column: SQL Server 2016 will lose extended support on July 10, 2026. Not that this is a surprise: Microsoft shifted its support lifecycle about eight years ago. SQL Server loses primary support at five years after release and is completely off support after ten years.

SQL Server 2016 was a big release for both Microsoft and me. I wrote the SQL Server 2016 training kit for Microsoft, worked on a book project, and filmed marketing videos for the release. Beyond that, I had one of the first customers live on SQL Server 2016 outside of Microsoft in July of 2015! I wanted to walk through some of the big features introduced in this groundbreaking version and how they affect SQL Server and Azure today. You'll also learn about how these features can help you more easily upgrade to a supported version of SQL Server.

Let's go back and talk about the recent history of SQL Server. In 2012, Microsoft made a lot of groundbreaking changes like Always On Availability Groups, the introduction of columnstore indexes, and several Azure adjacent features. For the most part, SQL Server 2014 didn't have any groundbreaking changes (writeable columnstore came along with in-memory OLTP), aside from changes to the cardinality estimator. SQL Server 2016 came at a time when Microsoft was behind on many industry trends -- like the widespread use of JSON and big data -- and, frankly, hadn't invested in security in a long time.

SQL Server 2016 tried to address all these needs. Support for JSON data was introduced, PolyBase allowed users to connect to data in Hadoop and Azure Blob Storage, and security features such as Always Encrypted, row-level security, and dynamic data masking were introduced in the 2016 release. Beyond those features, this was the last time Microsoft made major improvements to reporting services (SSRS), analysis services (SSAS), and integration services (SSIS) in a single release. Additionally, Microsoft acquired an analytics company, Revolution Analytics, and added the R statistical language to SQL Server via the newly created Machine Learning services.

The database engine itself got some key features -- the biggest being the query store, which Microsoft has continued to develop in every subsequent version of SQL Server. The query store is a downright revolutionary feature that collects in-flight query performance metrics and execution plans, allowing the DBA or properly trained system administrator to answer the question, "why was this report slow last Tuesday?" In addition to adding data collection points and query store customization, Microsoft has built additional features on top, such as automatic plan correction and parameter-sensitive plans. This is my favorite feature in 2016, and it's not even close. In my discussions with Conor, he discussed not only how much the query store has helped customers, but also how it has massively helped Microsoft manage Azure SQL Database by automating many manual query-tuning tasks.

The security environment in 2016 was not quite as tenuous as it is now with ransomware gangs and infostealers. Even in that environment, SQL Server still had several gaps in its security features -- the biggest was row-level security for user queries. Additionally, column-level encryption was in place, but there was no way to protect the keys from a malicious DBA, as they were stored in the database. Microsoft introduced a slate of security features into Azure SQL Database in the summer of 2015 to address these needs.

Prior to SQL Server 2016, all the in-database encryption options for SQL Server either stored the key within the database (column-level encryption), meaning the DBA could see the keys, or were managed completely outside of the database, which is a messy architecture. Always Encrypted, which still isn't as broadly adopted as it should be, stores the encryption key in the application tier, meaning the DBA can only ever see encrypted values. Row-level security effectively adds another WHERE clause, limiting which groups of users can see which row. Finally, dynamic data masking, a feature that obfuscates credit card numbers, phone numbers, and other PII, was introduced. This feature still stores the unmasked data in tables, so it's not a "database" security feature, but it does allow your app to be more secure and opens interesting possibilities for exporting test data.

I feel like I've barely scratched the surface of everything that was cool about SQL Server 2016, but it was groundbreaking in many ways as a database engine. My personal story was that I had my second consulting customer, who had a data warehouse that desperately needed some performance help. We also wanted to add scale-out capacity. The key to their performance was the use of columnstore indexes. In SQL Server 2014, those indexes weren't usable on availability group readable secondary replicas. I asked a colleague on the SQL Server team whether this would be fixed in the next version. The answer was yes, followed by “would your client want to join the TAP (preview) program”. The client said yes, so we got started. My favorite part of the story was when the client's lead developer asked whether the jobs were broken because they ran so much faster than before.

What does this end of life mean to you? It means that if you have SQL Server 2016 in your environment, you need to upgrade. My recommendation would be to go all the way to SQL Server 2025 -- we're far enough into the release cycle that most of the early bugs have been identified, and there are some key features (for example, query store on readable secondaries) that are beneficial to existing workloads, as well as new features like AI vector search.