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:
- 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?
- What is the impact of going multi-platform on the product family, engineering methodology, organization, and partner engineering organizations?
- 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?
- 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?
- 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.
Pingback: Why Not Port Microsoft SQL Server to Linux › Chuan's Blog
Hal, thanks for the post. This is really interesting subject to me because I’m a Linux enthusiast, but I think that SQL Server is a good product and we use it in company as OLTP.
Even as large as Microsoft is, I think you said it best; “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”.
I think the opposite is true of Oracle to some degree. Their DB may offer more functionality in certain aspects but MS SQL Server is not far behind and it is priced to sell. So, I think staying out of the *nix market was the right thing for MS.
Seems weird to port it back. As you pointed out, it was originally Sybase SQL Server on Unix that was ported to Windows. Porting it back to Unix now feels like using Google Translate to go from English to Russian and then back. It’s not gonna be quite the same thing.
Very insightful look into MS SQL server’s history. Given its early origins as a Sybase derivative and MSFT’s “integrated system” approach I didn’t think there would be such a serious advocacy/consideration to offer a UN*X port of MSSQL. I figured there were agreements with Sybase in place to keep from poaching the UN*X market they had.
I agree with you that keeping MSSQL Windows-only and leveraging the continuing integration with that platform was the primary force in the products success in the large midrange market (and for its toehold in the enterprise market). As to the succcesses and failures of platform-agnostic database vendors, I disagree that being “spread too thin” supporting multiple platforms and having to design to the “lowest common denominator” were the reasons for Informix, Sybase, Ingres, etc. fading into obscurity or retreating into a market niche. In fact there is more evidence suggesting that it was superior (at least in the price/performance sense) open source competition that foced consolidation in that market. Oracle succeeded because of the reputation of its products in the very large enterprise space where neither MS SQL Server nor the most popular open alternatives were traditional players.
MS SQL Server has a large presence in the midrange market mostly becuase its integration with Windows infrastructure and development tools (.NET stored procs, MSRS, visual studio data integration tools) are differentiators from what PostgreSQL and MySQL/InnoDB have to offer. The other closed-source cometition did not have any compelling differentiation from those open alternatives or Microsoft depite similar or higher TCO numbers. In fact, Informix’s flagship product was even a commercial fork of the same codebase that became PostgreSQL (When the Postgres research project at Berkley ended Dr Stonebraker took the resulting DBMS and made it a commercial product called Illustra, which was purchased by Informix and became Online Dynamic Server. Two of Stonebraker’s grad students forked the same code base and replaced the “postQUEL” query parser with a SQL parser to form the “postgres95” open source project which later became known as PostgreSQL). Just as Sybase is similar to MS SQL, Informix is too close to PostgreSQL to be worth paying so much extra for.
So, if MSFT had made a Linux or UN*X edition of its database at the expense of the differentiating features it now has there is a great liklihood it would succumb to the same fate against similarly capable open database engines like PostgreSQL
Very interesting read, not only from the SQL/*nix perspective, but also for software lifecycle planning in general.
Pingback: Oneda | Aconteceu no Twitter 75 - 24/07/11 a 30/07/11
Pingback: 2011 Yearly Link Roundup | Brent Ozar PLF | Brent Ozar PLF
I produced the following list of issues I would have expected to be considered before reading the article. Appears there are a number of unaddressed questions above.
Should MSFT take the SQL Server to UNIX?
– Does this fit into Microsoft’s larger corporate strategy?
– Will this cannibalise sales for Microsoft or its partners?
– Will this result in increased revenue for Microsoft?
– Will it be difficult technically to port SQL Server to Unix?
– Would UNIX itself need new features to fit the demands of SQL Server?
– Does MSFT have the technical resources in-house to make the port, or can it reasonably induce them to join?
– Is the current management of SQL Server competent to make this port?
– Would growing management to include new UNIX experts be politically damaging?
– Will the port actually provide value to users?
– Will it be faster overall than on Win32, or just save them operating system license and support costs?
– If faster, is MSFT willing to publish benchmarks showing SQL Server on UNIX is faster than on Windows?
– Are clients using enough unportable elements of the Windows platform they cannot readily switch?
– Will it result in increased support load to help clients with multiple platforms?
Article FAIL! SQL Server was ported FROM *nix in a partnership with Sybase that lasted until 1994.
DOH, I mean reader fail – sorry!
Sybase SQL Server was indeed multi-platform with Microsoft taking the role of the porting partner initially for OS/2 and later for Windows NT. The last “full” port was 4.21 released in 1993. At that point negotiations on ending the partnership were underway. Microsoft and Sybase disagreed on how two evolve SQL Server, with Microsoft wanting freedom to take it in its own direction. For Sybase’s part the original agreement precluded them from selling a Windows NT product. As the Windows NT market grew Sybase was finding itself missing out on a substantial amount of revenue (compared to what it received in royalties from Microsoft). Microsoft also had seen the Sybase System 10 code base and was “unimpressed” (actually I’m being kind as to what the team thought). So the two agreed to go their separate ways, with Microsoft gaining rights to the source code for 4.21 and Sybase freed of its Windows sales restrictions. The name “SQL Server” as well as APIs and protocols were shared between the two, though with the rampant success of Microsoft SQL Server Sybase eventually chose to change the name of their product. Microsoft then begain work on SQL Server 6.0, aka SQL95, which was the first version to really divert from Sybase. In particular, while Microsoft had been free to create its own tools as part of the porting partnership it had not been free to make changes to the relational server. After gaining full rights to change the server the original SQL Server team began to evolve the entire product, relational server included, according to its vision. SQL95 was Microsoft’s vision of how 4.21 should have evolved rather than the path Sybase was going down with the ill-fated System 10. Changes made to the relational server for SQL95 did not take into account any future possibility of porting back to Unix, though it wouldn’t have been that much work. SQL Server 6.5 (aka Hydra) was a quick turnaround release intended to finish what we started with the SQL95 effort. While SQL95 was being worked on the debate about the future evolution of SQL Server was taking place, with essentially three positions being advocated. The SQL Server team advocated continuing the evolution that started with SQL95, the JET (client database engine found in Access, VB, etc.) team advocated replacing SQL Server with a new JET-compatible server product based on a new storage engine (JET-Blue) they were working on, and David Vaskevitch (who had convinced Bill that Microsoft should get serious about the database market and orchestrated the split from Sybase) laying down a set of requirements that neither the SQL95 nor JET approaches could adequately address. This lead Peter Spiro, myself, and others who had joined Microsoft from outside to prefer a strategy of gutting the relational server and rewriting it using our own designs as well as integrating technology that the JET team was developing (specifically a new Query Processor, but not the JET-Blue store). After SQL Server 6.5 shipped we reorganized the team with Peter in charge of the lower half of the server and myself in charge of the upper half and began the rewrite that would result in SQL Server 7.0 (aka Sphinx). It is the line of products descended from and including SQL Server 7.0, including the about to be released SQL Server 2012, that is the true Microsoft SQL Server. Many Microsoft/Sybase SQL Server customers decided they preferred the path Microsoft was going down rather than the Sybase (System 10/11/12) path, and the same was true of ISVs (whom Microsoft had specifically targetted with Sphinx, but many of whom never ran well on the Sybase design), and so they kept asking Microsoft to port SQL Server 7.0 et al to Unix (and later Linux). And so while it is fair to say that a product named SQL Server once ran on Unix, and that a product named Microsoft SQL Server once was derived from the product that ran on Unix, that isn’t the product that has been on the market since 1998.
Hal – thanks for this wonderful reply! I’d originally read your article on too small a screen, too early in the morning, with too little sleep and no coffee – I almost immediately regretted the snotty tone in my post. I’m really glad that it prompted this great followup detail on the history of your products! Takes me back…
Speaking of coffee, I think it’s time for me to get another cup 🙂
Pingback: Porting Microsoft SQL Server to Linux « ABENDance
Great post – trust you are aware of the decision made as a part of SQL Server 2012 to provide connectivity from *nix clients to SQL natively – primarily a port of the ODBC native client on Linux. This primarily is a primary driver in the Enterprise space – primarily Tier 1 apps and helps customers bring in SQL as the database on the windows platform but keep their apps running on Linux for a while until they figure out the app roadmap.
Yes, and it’s a good decision. We originally tried to solve this problem in a couple of ways. The original SQL Server ODBC driver was licensed to a partner who ported and supported it on *nix. Unfortunately their business model was to sell ODBC drivers as a package to developers who needed a data-independence layer and that priced it out of reality for IT shops. I recall one NY-based bank that would have had to pay $1 Million to license the third-party offering just to cover the year use they would need while they ported from Sybase to SQL Server. At the same time J2EE use was exploding and we were losing a lot of deals for SQL Server when the customer (or ISV) had chosen Websphere or Weblogic for their middleware, so I prioritized getting a JDBC driver (i.e, new development) over taking back the ODBC driver and offering it on *nix ourselves (i.e., conversions). I’m happy that the SQL Server team eventually got around to an ODBC driver as well.
Pingback: Microsoft Office for Linux: Are people asking and answering the wrong question? | Hal's (Im)Perfect Vision
Kudos for a great article, and thanks for sharing that in-depth view of the history. I know I’m coming late to the game here, but is some of this tied into the reason there once was a MSSQL driver available in Linux for PHP use and later it was not? I remember we had to do something like either use a Sybase driver to get around the issue or compile from source until we….well, left that app as it was, which is where it linger’s to this day.
No relationship, the events I describe predate anything Microsoft did around Linux access other than licensing the Microsoft ODBC driver to a third party to port to other operating systems.
I don’t believe there was ever a Microsoft-supported Linux PHP driver for SQL Server, but I could be wrong. It almost sounds like you were using the FreeTDS.org support.