As most of you know, Exchange servers utilize the Extensible Storage Engine (ESE) database. As you have told us loud and clear, Exchange rocks from a performance, scalability, and availability stan...
Published Jul 16, 2009
Version 1.0
Blog Post
I agree with Paul. The current database technology is an administrative nightmare in large organizations with low IT salary budgets. To keep restore SLA's low and keep database performance acceptable, my organization has over 30 databases for our 1400 users. It does not have to be this way.
To those who are concerned about complexity or cost, there is absolutely no reason that SQL server could not be the underlying DB technology for exchange with no changes to the licensing or GUI administration interfaces. Yes, there would be a change in interacting with the database at the command-line and scripting level for backups and maintenance, but that's a *good* thing. As for cost, anyone suggesting that Exchange would "have to" get more expensive if it was running on a SQL database would need to explain why I wouldn't get a refund for my ESE database. The point of course being that software pricing is all funny money anyway, if MS wanted to do this they could.
But apparently they don't. The canned "it's not the right solution right now, but we'll continue to look at it" is the same thing MS said when 2007 and 2003 were released.
Here's a suggestion to MS: If you really don't want to put a decent DB backend on Exchange, at least let us run it on any DB that we choose. Continue to supply ESE with Exchange, but let teh customer substitute any SQL database for storage. That way you don't have to upset your SQLcustomers by 'giving away' SQL server, but the rest of us can make the choice to run a different backend. How about it?
To those who are concerned about complexity or cost, there is absolutely no reason that SQL server could not be the underlying DB technology for exchange with no changes to the licensing or GUI administration interfaces. Yes, there would be a change in interacting with the database at the command-line and scripting level for backups and maintenance, but that's a *good* thing. As for cost, anyone suggesting that Exchange would "have to" get more expensive if it was running on a SQL database would need to explain why I wouldn't get a refund for my ESE database. The point of course being that software pricing is all funny money anyway, if MS wanted to do this they could.
But apparently they don't. The canned "it's not the right solution right now, but we'll continue to look at it" is the same thing MS said when 2007 and 2003 were released.
Here's a suggestion to MS: If you really don't want to put a decent DB backend on Exchange, at least let us run it on any DB that we choose. Continue to supply ESE with Exchange, but let teh customer substitute any SQL database for storage. That way you don't have to upset your SQLcustomers by 'giving away' SQL server, but the rest of us can make the choice to run a different backend. How about it?