I’ve been asked many times over the years about a port of Microsoft SQL Server to *nix (as we used to call it, since Unix was the primary offering in the Enterprise while Linux was just gaining traction).  Most recently someone asked in a reply to one of my posts if Microsoft had ever seriously considered it.  While I can’t speak for any recent thinking, if you go back to over a decade ago it was given some very serious consideration.   There were three reasons for this.  First (and primarily), a number of Microsoft’s key partners (both software and hardware) lived in a multi-platform world and had a strong interest in seeing Microsoft SQL Server on *nix.  Second, this was the period when the highest end Windows hardware platforms were of the 8 processor variety and much of the competition amongst database engines was moving into the 16-32 processor range.  There simply was no Windows-based platform to compete against the Sun E10000 that had become the mainframe of the Internet (bubble) era.  As some may recall, even a couple of Microsoft’s acquired properties (e.g., Hotmail) used Oracle on big Unix boxes long after everything else had moved to Windows because there were no Windows equivalents (until the Unisys ES7000) they could move to.  Third, customers kept telling us they were happy to use SQL Server but didn’t want to use Windows NT 4.  And so, on a couple of occasions serious thought was given to porting SQL Server to *nix.

So why didn’t Microsoft take SQL Server to *nix?  On one occasion a partner commitment that might have made it viable failed to materialize.  On another occasion I initiated the investigation on the basis of a partner request but then decided it was a bad idea.  Here is why:

There are five things you have to consider when evaluating if Microsoft should take SQL Server to *nix:

1. What exactly is the product offering you intend to bring to *nix, does it have a real market there, and can you position the offering to succeed?
2. What is the impact of going multi-platform on the product family, engineering methodology, organization, and partner engineering organizations?
3. What is the business model, including how do you partner, market, and (very importantly) sell into the Enterprise *nix world when you are a company that has no expertise in doing so?
4. How do you provide Enterprise-class service for SQL Server when it is running on a platform that your services organization has no expertise with?
5. What is the negative business impact on with entire Windows platform associated with making a key member of the server product family available on *nix?

The product is always what people think of first so let me address it first.  When someone says Microsoft SQL Server you could think of two things.  One is the relational server(sqlservr.exe) that has its origins at Sybase and was re-written by Microsoft to produce Microsoft SQL Server 7.0 and later versions.  The other is that plus all the BI (Analysis Services, Reporting Services) and tools that are also part of the product family.  When someone talks about porting SQL Server to *nix the difference between just porting the former and porting the latter is at least an order of magnitude.  Maybe two.

Fortunately what people were asking for (again, over a decade ago,) was just the relational server.  The first order engineering of making that happen, assuming you disable some Windows-specific functionality, was rather small (on the order of a few manweeks).  But would a reduced functionality relational engine, without some popular features, be accepted as a serious offering by customers?   What of future planned (and now delivered) features like CLR Functions and Stored Procedures?  Would the lack of that functionality bother customers?  Would they insist we support Java Stored Procedures instead?  What about  management infrastructure?  Would SQL Server have to support different management infrastructures on *nix and on Windows?  Would we place new hooks in sqlservr.exe or would WMI/WBEM handle it all?  *nix DBA’s used shell scripts as their primary management tool, but the SQL Server of that day was not scriptable.  Would those DBA’s accept the use of GUI tools?  Would *nix users accept “Windowsisms” that made it quite clear to them that SQL Server was not a native *nix product?  On these last few points I had lots of historical evidence to suggest that *nix customers would not be happy about the situation.  They wanted a product that showed a full commitment to the *nix platform.  Which meant that far more engineering work than simple porting was required.  And then there was performance and scalability.  The effort to tune SQL Server to run well on a 32 processor E10000 running Solaris was going to dwarf the work to port it there in the first place.

The second thing to think about is how this is going to impact everything else around it, including the engineering methodology and organizations.  For example, do you follow a philosophy that says the core team just worries about Windows and throws the Windows product over the wall to a team that adapts it to *nix?  Or do you reorganize everything so you have a core team that builds multi-platform software and then teams that adapt it to the various platforms (which is what true multi-platform companies do)?  Do you stop putting in Windows-centric features such as CLR support to make multi-platform support easier?  Or can you get the CLR team to become multi-platform with you?  What about the Visual Studio and (what became) the Systems Center teams?  SQL Server takes components from many other teams, so what do you do about those?  Do you reverse the original decision to have a single SQL Server product (that included OLAP and the rest) and split out a relational-only product on Windows since that is all you are going to offer on *nix?  While a small contained project was possible, the changes likely required to succeed were earth shattering.

Third, engineering is one thing but everything else involved in bringing a product to market is even bigger.  Would customers really consider buying *nix products from “the Windows company”?  Particularly mission-critical Enterprise products?  How do you sell SQL Server on *nix when in fact you have no sales capability in the *nix world?  Not only that but how do you even get a sales rep to return the phone call when someone wants to buy $100K of SQL Server but no other Microsoft products?  What if it is only a $25K sale?  $5K?  Given how much energy goes into an enterprise-class sale, and particularly a database sale, a sales rep who went after these deals would not only never make their quota but they’d be losing money for Microsoft.  So you have to rely on partners to do the heavy lifting, but does that really help?  I was assured by some contacts that Sun would have welcomed SQL Server onto Solaris.  But could you have imagined a Sun sales rep bringing anyone from Microsoft into their account to help with the sale of SQL Server on a Solaris system?  I couldn’t.  It goes against all the rules of account control.   Perhaps if Microsoft created a dedicated SQL Server *nix sales team, who agreed never to pass information to the Windows Server sales guys, you could overcome this, but that greatly complicates the problem and raises the costs of the undertaking.  At the time Microsoft did not have dedicated sales teams for anything, so you’d be trailblazing yet another trail.  And then there is IBM.  An IBM sales rep is going to lead with DB2 and then bring in someone else if the customer insists on it.  Oracle’s existing market share means they are already in the account and are likely the ones encouraging the customer to tell IBM they want to run Oracle on the IBM Server.  But Microsoft didn’t have the same level of account presence, particularly with the *nix-oriented parts of IT organizations, to insert itself into these sales situations without a lot of incremental effort.  And that puts you back into the problem of the value of the sale being too low to justify that effort.  So this is another questionable partner situation.  While that left lots of other players (HP, Compaq/Digital, Dell, etc.) who could have been great partners, Sun and IBM were the two leading *nix players. Microsoft’s ability to penetrate the *nix database market without them would have been greatly impeded.

Fourth, since the target of my investigation was really mission critical Enterprise systems you have to address how they will be serviced.  How do you go after the most demanding service and support situation with an organization that has no expertise in servicing the environment?  Can you do it mostly with partners?  Again this is just complex and potentially expensive to solve.  It also flew in the face of something else we were experiencing.  Big Enterprise customers want your senior executives to shake their senior executives hand and promise you’ll stand behind them and make them succeed with your product.  How do you do that if you outsource service to a partner?  Would Microsoft have had to acquire a *nix-oriented services company in order to succeed?

Lastly, what is the business impact on the overall Windows Server business (or on Windows client as well) if you port SQL Server to *nix?  One could say this bullet is a duplicate of number three and it all washes out in the business plan.  But I doubt a SQL Server business plan could have fully captured the question or the impact.   I had full executive support in investigating a port, but had I brought forth a proposal to proceed  I would have faced arguments from many that I was undermining Microsoft’s entire business plan.

I started to work through all of the above and realized that the cost of porting SQL Server to *nix, and succeeding with it, was enormous.  And more importantly, it would distract from our ability to move the product forward.  It would also distract from Microsoft’s ability to push Windows Server to support high-end hardware and address other Enterprise requirements.  And when all was said and done that it was going to be a huge net negative for the business.  So I dropped the idea.

Fortunately for Microsoft the collapse of the Internet bubble, and its assumption that businesses would grow faster than Moore’s Law for an indefinite time period, coincided with the release of Windows 2000 Server.  Windows 2000 Server addressed many of the problems (reliability, scalability, manageability) with Windows NT 4 Server in the Enterprise.  The combination caused customers to apply a price for value analysis (that they’d ignored during the bubble) to their server purchase decisions.  And high-end hardware such as the Unisys ES7000, HP Super Dome, and offerings from Fujitsu, NEC, and others essentially wiped out the single system *nix scalability advantage.  Windows Server then continued its Enterprise-oriented improvements in subsequent releases, helping pave the way for SQL Server to grow its success in the Enterprise without a *nix port.

Has Microsoft taken another look at a port since I left the SQL Server team?  I don’t know.  Some of the pressures to port SQL Server to *nix have receded over the years while others (e.g., MySQL) have emerged.  But I think it is an idea whose time has passed.  In a Cloud Services (as opposed to just hosting a standard VM in the cloud)environment no one really knows nor cares what the underlying OS is.  SQL Azure thus becomes Microsoft’s answer for those who don’t want to run an in-house Windows Server just so they can run SQL Server.

There are times I think Microsoft would be better off as a pure software company rather than one oriented primarily around a single platform (i.e., Windows).  On the other hand, when I look at the database industry I see that most of the database companies that became leaders based (to a large extent) on their multi-platform support are gone or are niche players.  Ingres, Sybase, Informix, and Oracle all used multi-platform as their means to displace the systems vendors own offerings (DEC Rdb, IBM DB2, and non-relational offerings from many others).  Of those only Oracle remains a significant supplier of database software.  And while some may consider multi-platform orthogonal to the problems the other database companies faced I think it played a significant role in their inability to keep up.  Doing multi-platform right is a huge and ongoing expense;  A tax on their ability to invest in improving their own database technology and focus their sales and marketing efforts.  By sticking with a single platform Microsoft, SQL Server included, gets to focus its engineering, marketing, sales, and services efforts on adding synergistic value instead of thinly spreading a least common denominator over multiple-platforms.  This has been key both to Microsoft’s overall success, and specifically to SQL Server’s success.

In retrospect I can say I’m very happy that we never went the multi-platform route with SQL Server.   Even if I was the primary advocate in the management team for doing so.