Microsoft Exchange Server Not Going SQL Back End, for Now

According to this recent statement from Microsoft, Exchange Server 2010 will not move to a SQL back-end.

This confirms that a possible port from the Extensible Storage Engine (ESE) to SQL has not simply been a rumor, while leaving the door open for future post-Exchange 2010 releases to use a SQL store. As noted in one of the reader comments, and I well remember, hot discussions around ESE vs. SQL have been a part of most major Exchange events going back at least to MEC98 in Boston. Microsoft does not typically make major development investments with no reason, so one has to wonder if this is indeed a statement of future direction — to invest in ESE and forget about SQL — or simply an attempt to manage expectations around Exchange 2010? We suspect the latter.

Many factors can influence such a major technology decision in a product release cycle — ranging from technology integration hurdles, scope/schedule/cost factors, possible political challenges between the Exchange and SQL teams, and overall prioritization set against other features, to mention a few. Did the port to SQL simply not make the cut for Exchange 2010? Or was there too much risk in making such sweeping changes in a single release?

One of Microsoft’s top priorities in Exchange 2010 has obviously been to enable Exchange Online in several overarching ways, namely:

  • To let Microsoft use Exchange 2010 in its data centers to facilitate better operational efficiency (and ultimately to compete with the likes of Google).
  • To let customers choose to move from on-premises Exchange to Exchange Online and to provide some migration tools in the box to do so.

Meeting the first of these objectives has necessitated substantial back-end investments around database portability, site level resiliency, and other high-availability features. Making such extensive changes combined with changing the database itself would impose a massive amount of risk into the Exchange code base, and would have been a factor for the decision.

But it’s interesting to note that a number of changes have been made in Exchange 2010 to isolate the store from other components. For example, the introduction of MAPI in the Middle Tier (MoMT) serves to isolate Outlook client calls from going directly to the back-end database, which would have posed a serious problem or become a blocking issue for Outlook clients (which are largely MAPI-dependent) if a move to SQL was planned. So why did Microsoft invest in technologies such as MoMT? Enabling more database portability for cloud computing is obviously one part of the equation, but is there more at play here?

While it would have been nice to have a definitive statement that SQL won’t ever be a back end to Exchange, that sort of long-term roadmap is hard to predict in the technology world, and Microsoft did well to buy itself some breathing room with the “we continue to evaluate technology options” comment — which is the right thing to say — so the rumors will continue to swirl.

And based on the timing — Microsoft is probably in the planning stages of Exchange “15,” the next version of Exchange after Exchange 2010 — we suspect Microsoft wrote this statement to spawn some discussion on the whole debate and gauge demand for a move to SQL. If this is something you feel passionate about, we’d like to hear from you. The ESE vs. SQL argument is not quite ready to die yet.

David Sengupta

Post a comment

You must be logged in to post a comment. To comment, first join our community.