Per-Server Database Limits Explained
Published Jun 04 2013 07:45 AM 47.1K Views
Microsoft

Over the past year, we have discussed the architectural changes that have been introduced in Exchange Server 2013. I wrote about the reduction in complexity that the new server role architecture introduces, as well as, the one of the new capabilities introduced in Exchange 2013, Managed Availability’s recovery oriented computing. However, we haven’t been clear on other architectural changes that have shaped decisions we’ve made about the Exchange 2013 product. For example, the decision on reducing the number of databases supported per-server from 100 to 50. There were three main reasons for this:

  1. Server architecture changes
  2. Use of commodity hardware
  3. Testing

Let me explain each of these in more detail.

Server Architecture

Exchange 2013 includes fundamental changes to the search and store components and data is processed and rendered.

The old content indexing service was replaced with Search Foundation. Search Foundation is an actively developed search platform that is used across the Office Server products. Search Foundation allows us to have notification-driven content indexing which improves indexing performance; in addition, we now annotate during transport, reducing the number of times a message must be indexed significantly.

The monolithic store.exe process was re-written; store is now written in managed code and there are now at least three processes that make up the Information Store service: The Microsoft Exchange Replication service, the Information Store service process controller, and the Information store worker process. By utilizing the worker process model, each database is now isolated from every other database (e.g., a database crashing due to a malformed message will not bring down the rest of the databases on the server).

In addition, there is a core shift in the server role architecture such that the protocol responsible for servicing a user’s request is the protocol instance that is local to the user’s active mailbox database copy. This means that the Mailbox server role now performs more work when compared to its Exchange 2010 counterpart.

The end result is that with the server architecture changes we introduced in Exchange 2013, search, store, and the protocols typically can be CPU and memory bound, as opposed to disk IO or capacity bound.

Commodity Hardware

As discussed in our server sizing guidance, we are big fans of commodity server hardware. Office 365 is designed to run on commodity hardware that leverages 2 processor sockets and 12 disks – we do not leverage external storage chassis as this increases the operational complexity in the environment. Our Exchange 2013 Mailbox servers have less than 50 database copies per-server in Office 365.

Testing

The last reason as to why we limited support to 50 databases per-server is that we did not have actual deployments at any scale to validate that store, search, the protocols, and Managed Availability could handle 100 databases per-server. Automation and lab testing can only take you so far; the lack of real world usage was one of the key reasons why we chose to limit the database count.

Moving Forward

The Exchange Product Group takes pride in the feedback mechanisms we have invested in with the Exchange community. Since the release of Exchange 2013, we’ve received an inordinate amount of feedback regarding the reduction in supported databases per-server. The driving response has been “we currently deploy more than 50 databases per-server in Exchange 2010; with this change, this means we will need to deploy more servers, which increases our capital expenditures significantly.” Rest assured, that is not the message we want with Exchange 2013. It is true that Exchange 2013 utilizes more CPU and memory than its predecessors – this is due to the architecture changes we’ve made, as well as the changes we’ve made to reduce disk IO, so that you can deploy more mailboxes per disk. But we do not want to see architectures artificially limited by the supported databases per-server constraint.

Over the last several months, we’ve been working to resolve our concerns and improve our test matrices to validate supporting more databases/server.

As a result of the work done by the Mailbox Intelligence team and Operations teams, I am pleased to announce that when Exchange Server 2013 RTM Cumulative Update 2 (CU2) releases we are increasing the number of databases per-server back to 100. Both the Exchange 2013 Server Role Calculator and our sizing guidance will be updated to include this architectural change in tandem with CU2’s release.  CU2 will release later this summer.

As always, we continue to identify ways to better serve your needs through our regular servicing releases. We hope you find this architectural change useful. Please keep the feedback coming, we are listening.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

9 Comments
Not applicable

Ross,

Does o365 use an off the self server from a vendor like HP, DELL, etc... or something custom?

Not applicable

Yes, but, do we still have to stop all of the other databases in order to change or add a new database? The methodology in Exchange 2013 still feel unpolished when you compare things to how Exchange 2010 worked. Exchange 2010 has ALWAYS worked with 100 databases, so more than 6 months after launch Exchagne 2013 is barely catching up with what we used to have.

Not applicable

Its great that we have now recommending DBs/Server to 100..

Not applicable

I have problem with install office 2007 it says to me "the language of this installation package is not supported by your system" how can I fix that.

plz contact  to my e-mail ozico@live.com thx

Not applicable

Ross why would you just simply say that due to the above you do not recommend morea than 50, or did you simply guess this number ?

Not applicable

This is awesome!!

The cost associated with doubling the amount of servers - just to accommodate the current 50db limitation is definitely a constraint with large scale deployments. Especially for Organizations trying to maintain small databases.

Dame

Not applicable

Great news. However, it just emphasizes the point that Exchange 2013 was released way before it was really done. We are hoping that the Service Pack 1 release will finally contain all the features promised in the RTM. Exchange 2013 appears to be about 1 year behind schedule.

Not applicable

So the "news" is that finally 13 has the same database limits as 10 did when it launched 4 years ago and 13 is still less functioning that 10 is even with CU2 in the works. Am I missing something or is this a joke?

Not applicable

Can we expect CU2 released by end of this month (end of 2nd quarter), or it might be slipped again? :)

Version history
Last update:
‎Jul 01 2019 04:13 PM
Updated by: