The Costs of Running SQL Server on Linux

If you’ve followed Scott Guthrie’s career at Microsoft, you’ve seen him and his teammates facilitate an increasing degree of coziness between Redmond and Linux. First, when the Mono Project began porting ASP.NET to Apache, the ASP.NET team didn’t respond with hostility, but instead, seemingly bent over backwards to open-source their code as a means of helping support this initiative.

Later, as Guthrie was steering Microsoft’s Azure cloud platform, he helped create yet another stir when Microsoft started unapologetically hosting Linux VMs and associated services along-side their own Windows-based services and solutions. As such, now that Guthrie is Vice President of the Cloud and Enterprise Group, it seems fitting that he was the one to announce the bombshell that Microsoft is actively working on a version of SQL Server that’ll run on Linux.

As a SQL Server consultant, my thoughts about SQL Server running on Linux are mixed. On one hand, this bold and exciting move means that Microsoft isn’t complacent about SQL Server’s capabilities or market-share, which should hopefully bode well for me and my mortgage. That, and I’m curious to see what this will portend lower-end workloads running atop SQL Server Express. Ignoring for a second the horror of what may become a vast sea of WordPress databases running atop smaller Linux VMs outfitted with SQL Server Express Editions, the reality is that for many smaller database needs, Windows itself adds in enough bloat and overhead that the prospect of running SQL Server Express on smaller Linux hosts, for things like IoT storage, seems quite appealing. Professionally, I’m also very interested in seeing how SQL Server stacks up against larger, highly-concurrent, workloads on Linux as well — because my expectation is that SQL Server will progress towards providing Oracle with some serious competition.

On the other hand, part of me is a simultaneously a bit worried and even cranky about Microsoft porting SQL Server to Linux, largely because of the costs involved. SQL Server, as you may have noticed, isn’t cheap to license. Yet for years now the SQL Server team has cultivated a seemingly hostile culture towards dealing with bugs surfaced by paying users on their Connect site. Over and over again, significant bugs will linger on Connect, amass large numbers of confirmations or ‘up-votes’ from other customers and community members only to eventually be dismissed with the notorious “Closed as won’t fix” status — meaning that Microsoft tacitly admits there’s a problem, but apparently just doesn’t have enough internal resources to address the problem.

Now it seems that instead of hiring additional resources to help address these existing problems, Microsoft is spending money to chase after new customers while dutifully copying known issues and problems with SQL Server over to Linux. Granted, that summary of the situation makes it sound like a simple binary problem where Microsoft can either expend resources to tackle known issues or ignore existing problems (i.e., customers) in pursuit of new and exciting adventures.

The problem, of course, is that the situation is not that simplistic. More than likely, the level of talent needed to fix and address known SQL Server issues is simply not available (at effectively any price) and that bringing in additional engineers to migrate SQL Server to Linux is not “taking away” from a talent-pool that would otherwise be address these problems. That said, I’m still hopeful that Scott Guthrie’s leadership will still help remove some of the seeming animosity that the SQL Server team has for their customers (via the Connect site) as SQL Server simply costs too much for customers to end up feeling like the problems and bugs they run into with it are a ‘burden’ for Microsoft.

Long term, as exciting as SQL Server on Linux looks like it will be, it’s hard to not see the decision to take SQL Server to another platform as not, somehow, involving a bit of a trade-off and incurring some additional costs and concerns as well.