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?

Discuss this Article 2

You are right Paul. Moving to another technology is not only an invitation to complexities but also a alot other challeges for new deployemts. Especially when a very complex organization is to be setup it would be really very tough for architects and the administrators to design two different technology co-existance. On the other hand some features from SQL are really great and can really enahance the storage as well the end user experience. Log shipping and DAG are the best examples of it. Content Indexing is another superb example that how CI 3.0 provided a much faster way to search through store contents.
Personally, I would favor the concept of staying on ESE and let it be managed by Exchange itself. Perhaps, SQL and Exchange together wont be very much compatible with each other from management perspective. Several other situations like DR also need to be considered too. Long story short, I am with you on it and would love to stick with ESE however, enhancements to ESE itself are welcome.

I feel the article was poor. It did not explained anything. For example was it only paper practice? Etc...
About the topic, if such a decision will be made do you really believe MS will required you to install at first SQL and then Exchange? More likely I feel the solution will looks like OCS deployments. Standard server for small business install SQL as well, but total without admin effort. On the enterprise level you will go to SQL hotels etc..
And in honest, how much you are modifying ESE engine and configurations today?

Related Articles

John Savill's Hyper-V Master Class

Join John Savill for 12 hours of comprehensive Hyper-V training. This master-level online training course will explore all the key aspects of a Hyper-V based virtualization environment covering both current capabilities in Windows Server 2012 R2 and looking at the future with Windows Server vNext.