Actually the title should be SQL Server vs. ESE, which is the proper name for the database engine that Exchange uses. It's the Extensible Storage Engine (ESE), which is more commonly known as the JET engine and is going to be used in the upcoming Exchange 2010 product. This technology has been used in Exchange for years, though it has been enhanced for each new version, including Exchange 2010.
However last week the Exchange team noted in a blog that not only had they considered using SQL Server instead of ESE, they had actually gotten it working. Even though this was the case, the blog mentions says that apparently SQL Server wouldn't necessarily meet their needs for the enhancements they wanted.
"It was ultimately determined that the best way to ensure we could drive compelling innovation into Exchange for 2010 and beyond was to remain committed to ESE."
There weren't specific reasons given for the deficiencies in SQL Server, but instead they mention that ESE would give them some significant HA, performance, and storage cost reductions after it was enhanced. I also saw a note that many businesses couldn't afford a SQL and an Exchange license, but I would think that the SQL Server engine could be embedded in the Exchange product without the need for a separate license.
That seems strange to me, since I'd think that SQL Server would provide a great platform in which to store mail messages. SQL Server 2008 includes so many enhancements to move beyond relational storage, like the Filestream data type, that I'd expect it would easily handle Exchange needs. In addition, the backup and recovery capabilities of SQL Server are well known, and it would reduce (somewhat) the skills needed by administrators.
It makes me wonder if there weren't disagreements between these two teams, or perhaps a NIH (not invented here) syndrome being perpetrated by the Exchange group. Maybe the SQL Server team won't provide the enhancements that the Exchange team needs, or maybe not in a timely manner. However I'd think that they could include them in a future version, or they'd have built them into SQL Server 2008 at the request of the Exchange group.
It would seem to me that there would be some efficiencies gained and costs reduced by not having a separate database engine for different products. In these times when cost cutting is hitting all companies, including Microsoft, this move surprises me.
But maybe it's a strategic move. Perhaps the work on a separate storage engine fosters some competition, or even allows new ideas for database structures to be developed independent of SQL Server, and without the baggage that comes with long term development on a product. Perhaps we'll even get some ideas from ESE fed back into SQL Server at some point.
Steve Jones