Brent Ozar had a post SQL Server 2016 and the Internet: Forced Updates, Phoning Home. "Issue #1" is ‘You probably shouldn’t run 2016 side-by-side with older versions.’ So, I checked the language in all the SQL Server install ULAs and they all say the same thing. I know some shared components will be upgraded to the newest version on a server upon install of said version and feature, but this has been around for many Glenn Berry guided instance installs. Is there something I’m missing?


2 Answers 2


It's important to read the reasons pertaining to this freighting revelation

this software will automatically update and replace certain files or features within those editions with files from this software. This feature cannot be switched off.

The way I read that, the concern is the potential for one version to overwrite at a later point in time the files shared and needed by another version. This is probably a result of DLL Hell. You can see this on the Wikipage,

Sometimes, the OS itself removed or replaced DLLs with older or obsolete versions. For example, Windows 2000 would install black-and-white printer DLLs on top of color-aware DLLs, if a black-and-white printer was installed after the color printer.

In light of that, the suggestion not to run two versions side-by-side makes perfect sense.

Future Safeing the Problem

One way to avoid DLL hell, is to upgrade and install Ubuntu which doesn't have such a problem. SQL Server 2017 will run on Ubuntu. This means that SQL Server 2018 will likely also run on Ubuntu. At such time, you'll be able to run both versions concurrently. So it's nice to see the Linux work paving the way forward. For Linux, SQL Server is currently self-contained in the /opt directory, and packaged officially with dpkg (which supports multiple versions).

  • We have multiple servers running more than 2 versions of SQL Server and have never had issues with "DLL hell". Microsoft works very hard to ensure this kind of environment is supported and works well.
    – Hannah Vernon
    May 24, 2017 at 21:34
  • As a programmer, the question ultimately boils down to having total-concern, or no-concern. I would have no-concern if the installs were sandboxed from each other did not touch shared libraries. I would be totally perturbed if there were two competing updater's managing the same files. Without revealing my opinions of Microsoft's QA, it's far from bulletproof and we should not be trusting it (regardless of it is trustworthy). May 24, 2017 at 21:38
  • The SQL Server binaries themselves are sandboxed, and completely independent. The components referred to in the CYA EULA are optional and not related to the Server components themselves; think SSMS, etc.
    – Hannah Vernon
    May 24, 2017 at 21:56

At the risk of speaking directly for @BrentOzar - I don't think he's saying you can't install SQL Server 2016 alongside a prior version. His blog post1 states:

You probably shouldn’t run 2016 side-by-side with older versions because:

... You may get updates whether you want them or not.

This does not say you will get updates that will bork your box. Essentially, any Enterprise installation of SQL Server should be carefully managed - you probably shouldn't allow automatic updates of SQL Server at all, and I'd be quite afraid of letting Windows Update install any updates automatically without some kind of pro-active management.

Test your planned deployment on a non-production box to see if the installation of SQL Server 2016 will cause problems for your environment. Then make an informed decision about how to go about applying updates. Decide for yourself if you can afford the risk of a side-by-side installation, versus the extra cost of running multiple SQL Server boxes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.