In the mid '90's MSFT did an audit & found it was developing 42 different database engines, most used internally for features within each product. So the paper recommended they consolidate to just 4; a Server DBMS (SQL), a lightweight desktop DB (Access based), a streaming media server & one other I've forgotten. So over the next few years much of that consolidation took place. Hence System Centre & other products now use SQL. It is also why they invested so much work in WinFS (while this hasn't shipped in the OS, it was the basis of many of the new storage capabilities in SQL 2005/8).

Around SQL2000 timeframe it was planned to have Exchange use SQL. To that end the company re-orged & both teams reported into the same VP. But at the time there was too big a gap, SQL was relational & didn't support text really well. Exchange was highly optimised for text especially in areas of compression & splitting/storing message fragments. The result was SQL2000 was 15 times larger than the equivalent in Exchange. And one of Exchange's biggest issues was its customers where hitting database size limits.

So this work was parked while SQL improved its ability to store non-traditional data ie: Features like XML, Varchar(MAX), Integrated Full Text Search rose in priority which caused other really cool features to be pushed into the future.

In short. Using SQL within Exchange is not a new idea within Microsoft. Yes, there are things to consider; taking a dependency on another team, pricing (ie: is SQL embedded for free), is it feasible.

It should not surprise you that they review these questions from time to time. With each SQL release the gap gets smaller. So I expect that sometime in a future release this integration is likely to happen. Until then you should not infer anything about SQL's suitability for the task. There are a huge number of features Microsoft would like to put into both SQL & Exchange. Unfortunately, like every business, they have a finite dev/test capability. Doing the integration work would push other features into a future release. This feature trade-off is always unpleasant; it’s like being forced to choose which of your babies gets to live. There are some really exciting features slated for the next 2 major SQL releases, I'd hate to see any of those dropped in order to complete this integration work. But perhaps they will, I’m no longer in a position to vote.

Thanks for your interesting article.