Which Version of SQL Server is Best?

There are currently six major supported versions for SQL Server. SQL Server 2008, 2008R2, 2012, 2014, 2016 and 2017. This doesn’t include the permutations of service packs, cumulative updates and hot fixes that have been released. In this short blog we will review some options for patching, and how you can position yourself and your company for the future. 

Plan for a minimum of SQL Server 2014 

First, we should examine SQL Server major versions and lifecycles. SQL Server 2008 and SQL Server 2008R2’s Extended Support Date expires on July 9, 2019. If you are on these versions, you should begin plans to upgrade and avoid any new installations.  The major releases of SQL Server 2012 and beyond appear to have about five- to 10-year lifecycles depending on your mainstream and extended support options. 

SQL Server 2012 is already off mainstream support and on extended support, and SQL Server 2014 is the oldest version still on mainstream support. If you are installing a new server, you should plan on a minimum of SQL Server 2014. If you are upgrading, please plan on extensive testing as a new cardinality estimator was introduced in SQL Server 2014 which may change previous performance. 

Strongly consider SQL Server 2016 as it will have a longer lifecycle and is touted for its performance increases – “it just runs faster.” SQL Server 2017 was released in October 2017 and while the negative stigma of running anything Microsoft v1.0 has diminished, it may not be your first choice unless you like to be on the forefront of technology.

Patching shifts to cumulative updates 

Microsoft has recently changed some “rules” for their servicing model.  In 2016 there was a push to patch cumulative updates (CUs) as soon as they became available. Microsoft committed to certifying the CUs to the same level as service packs (SPs).  With SQL Server 2017 and beyond Microsoft will no longer be producing SPs, only CUs. This is part of the emphasis to delivery new content faster which will help level the playing field with Azure. 

Traditional SPs also have an expiration date that may differ from the major version lifecycle. Typically, an SP expires about one year after the next SP is released (e.g. SP3 expires one year after SP4 is released).  As in the case with the Meltdown and Spectre security patches, they were only released for supported SP versions. If you were not on a supported service pack, you first needed to upgrade to a supported service pack and then apply the security patch. 

For SQL Server 2017 and beyond, there is no clear information on whether or not CU support will expire like with SPs. The Microsoft blog reported that this would be handled “on a case-by-case basis.” These incremental updates typically only take 15-30 minutes to install including reboots. If you have prescribed maintenance windows where you can absorb the short outage you should attempt to stay up to date on security releases, service packs and have an implementation plan for SQL Server 2017 CUs (e.g. quarterly).

When looking at lifecycle, patching and security, I would look at SQL Server 2016 SP1 CU7 13.0.4466.4 as my starting point. This allows us to run on a vetted, supported, secure and performance–enhanced platform. I strongly recommend performance testing due to the new cardinality estimator and I would plan on working a SQL Server CU patch upgrade release cycle into my application development rhythm.

Subscribe to our blog for more on the latest hybrid IT insights.