We often receive the question “What are the IOPS requirements for Dynamics CRM” (or some form of that question).  On its surface, the question sounds like a fair question that should have a short answer.  In practice, the answer in much more complex than expected.

When planning for your Dynamics CRM deployment, the discussion of storage requirements can consume a significant amount of time to make sure that the allocated space is done right the first time.  The most common planning indicators that we’ve seen customers use are projected database size and IOPS requirements for the CRM databases.  In this post, we will focus the discussion on the latter.  Also, for the purposes of this blog post, we will only be referring to the organization (tenant) database.  The MSCRM_CONFIG database, while important, has minimal IOPS requirements.

A Nod to Database Size

As you well know, Dynamics CRM is a very flexible platform.  This flexibility means that accurately projecting database size can be a challenging task.  The number of custom entities and custom attributes (including their data types) can have a significant effect on database size.  Additionally, Dynamics CRM makes extensive use of variable character fields.  While these data types help limit the size of your database, they make predicting storage space requirements more difficult.

Finally, storing attachments or large files to notes in the Dynamics CRM database will account for the most explosive growth of your _MSCRM database.  If you choose to store these files in Dynamics CRM instead of Sharepoint (or another document storage solution ), it will be very important to keep an eye on your database size and growth rates for backups and to avoid outages.

Obviously, there is more to say on this topic.  For the purposes of this blog post, we will set this topic aside, except to remind you to be mindful of storing attachments and the number and definition of custom entities and attributes.

IOPS – Clarifying the Discussion

We’re defining IOPS as the unit of measure for input/output per second of a _MSCRM database.  We’re making the assumption that we will primarily have random reads and sequential writes.  That is to say that the reads will be randomly from the data (mdf) file(s) and the writes will be sequentially to the tail end of the log (ldf) file(s).

IOPS Requirements for Dynamics CRM

When planning for your Dynamics CRM deployment, the most accurate way to determine your IOPS requirements will be to conduct a load test of your deployment (including customizations and reporting) and calculate your IOPS requirements while the system is under load using your proposed transaction volume.  We have worked with multiple customers to work through this exercise and help define both server and storage requirements for their Dynamics CRM deployment.  For a vast majority of these exercises, we have used the Dynamics CRM Performance Toolkit.  The Performance Toolkit is a free tool available for download that can be used to introduce load and benchmark your Dynamics CRM system.  If you’re interested in conducting such an exercise and would like assistance, please let us know and we can help you get the answers to your infrastructure questions.

If conducting a load test is not an option, we will do our best to give you some guidance around IOPS requirements for Dynamics CRM that we’ve observed from benchmarks that we’ve done in our performance lab.  Please note that these are not official requirements for Dynamics CRM, these are simply shared to provide some context around what we have seen in our performance lab with some of the benchmarking that we have done. 

Our testing has showed that because Dynamics CRM is used in so many different ways, the IOPS requirements for different workloads vary significantly.  Additionally, tuning Dynamics CRM has a major impact on your IOPS requirements (more on this later).  The following tables outline the performance counters that we measured and the IOPS observed for various benchmarks that we’ve conducted, as well as a brief description of the workload. 

Performance Counters



Disk Reads / sec

Shows the rate, in incidents per second, at which read operations were performed on the disk

Disk Writes / sec

Shows the rate, in incidents per second, at which write operations were performed on the disk

IOPS Recorded


IOPS Write




Read intensive workload with a 1 TB database



Large volume of  reporting and search with a 1 TB database



Large volume of  reporting and search with a 1 TB database



Mixed workload – write heavy



Mixed workload

As you can see, the results are sporadic and largely dependent on workload, tuning completed, and transaction throughput.

IOPS and Tuning Dynamics CRM

There are many reasons to tune Dynamics CRM and IOPS is towards the top of the list.  We have found that tuning Dynamics CRM has a major impact on IOPS requirements.

Consider a scenario where SQL Server must scan an entire table in order to find the records that it needs to satisfy a query (like a quick find or a saved view).  If the table is large, scanning the entire table (and tables included in the joins) can be an expensive process that requires a large amount of work from the disk subsystem.  Tuning that query will make it run much faster (better end user experience) and require significantly less from the disk subsystem thus reducing the IOPS requirements from the storage.

If possible, tuning Dynamics CRM should be included into deployment plans and implemented pre go-live in order to avoid surprises with under-sized environments or poor end user experiences.

The Story Continues…

In short, IOPS requirements for Dynamics CRM are a moving target.  We’d be happy to add to our table above based off of performance characteristics that you are seeing.  If you’d be interested in sharing your observations around IOPS please share them with us and we will add them to the results above (anonymously – of course).

Thanks for your time!