SQL Server for Exchange: Tested and Rejected

Some things are meant to go together: hot dogs and baseball, chocolate and peanut butter, and torque and recoil are great examples. However, other things—oil and water, for instance—don't mix. Which category do Microsoft Exchange Server and Microsoft SQL Server belong to?

Thanks to a blog post last week, we now know how Microsoft thinks these two major server products fit together. In short, they don't. The Exchange team disclosed that it tested but decided not to use SQL Server as the base database engine for the next version of Exchange. Microsoft has long been rumored to be working on a project to move the Exchange data store to SQL Server, and in fact a version of the technology code-named Kodiak was developed and tested some time ago. Why didn't Microsoft proceed with the integration?

The Exchange team blog post gives a pretty clear answer: They wanted to concentrate their efforts on building Exchange-specific features rather than on customizing SQL Server or retrofitting Exchange to work with SQL Server. Despite the fact that the initial integration work had already been done, and that, according to the blog, performance was good, combining these two very different technologies would have required a huge effort—effort that was better spent elsewhere.

I think there are a couple of secondary reasons for this decision, too. First, customers weren't asking for it en masse. IBM's experience with DB2 support in Lotus Domino is an instructive precedent. In a bid to satisfy requests from a few large customers, IBM added DB2 support in Lotus Domino 7.0, but it was only available upon request. Later versions of the product dropped DB2 support altogether due to a lack of customer demand, essentially wasting all the hours spent to implement and support that feature. Second, there's the whole set of problems surrounding how you enable coexistence and migration between on-premises and hosted Exchange when either end could be using either Extensible Storage Engine (ESE) or SQL Server. That's not an easily solved problem!

Most of the customers I've encountered who have expressed interest in SQL Server as an Exchange storage back end are familiar with SQL Server, and in fact most of them tend to come from large enterprises where there's already a substantial stock of SQL Server expertise. For those admins, having Exchange mail data be just another set of tables in an existing SQL Server farm probably makes good sense because it lets them leverage investments made in their SQL Server deployments.

For everyone else, though, moving to SQL Server would probably require significant investments, starting with a new set of skills. The tools, processes, and concepts that SQL Server requires are almost 100 percent different from those of Exchange. Imagine a world where Exchange admins do everything they now do, but also have to manage an underlying set of SQL Server databases. Licensing cost is another potential sticking point; SQL Server uses a completely different licensing model than Exchange does. Of course, Microsoft could change their licensing to eliminate this problem, but it's not clear that they would immediately do so.

Interestingly, you can already see SQL Server's influence in Exchange in several ways. SQL Server's log shipping functionality clearly inspired the log shipping technologies in Exchange 2007 and the forthcoming Exchange 2010, and the availability model in Exchange 2010's database availability groups is much closer to SQL Server's model than the single copy cluster. I expect that we'll continue to see cross-pollination of technologies between these two products, but I'm glad that Exchange is staying on the familiar and proven ESE technology. How about you?