Because SharePoint is heavily dependent on SQL for its storage needs, the proper allocation of storage resources is a critical design element for the SharePoint farm. This design can be broken down into two major components, storage and I/O operations per second (IOPS).
Storage variables
Storage is simply the amount of available space configured for a particular database. If the database happens to be a content database, the overall size of the database can vary dramatically based on two features: recycle bins and auditing.
Recycle bins are enabled by default at both the site (web) and site collection (site) levels. A document that is deleted from a site occupies space in the associated content database until it is deleted from both the first and second stage recycle bins. If you foresee the need to delete many documents in the interest of reclaiming space, the documents must be deleted from both recycle bins.
Auditing can place a lesser storage demand on a content database. If you expect to use auditing in a particular content database, try to restrict the levels at which it is enabled rather than enabling auditing on entire site collections.
Recycle bins are some of the most straightforward and most misunderstood components in SharePoint. Knowing and understanding the behaviors of how a document moves from one stage recycle bin to another is key to understanding how documents that are “hidden” might be consuming space.
I/O operations per second (IOPS)
IOPS is the measure of how many input and output operations per second are available from your I/O subsystem (storage). The storage configuration influences both the read and write speeds available for use.
Stress testing a storage subsystem enables you to know the limits of your storage and also gives you an opportunity to tune it to your requirements. There are three main tools used for this purpose (see Table 1), each of which is free of charge:
TABLE 1 I/O subsystem testing tools
| Tool | Provided By | Purpose | Download Location |
| SQLIO | Microsoft | Performance capacity (single I/O type at a time) | |
| IOMeter | Open Source | Performance capacity (combination of I/O types at one time) | |
| SQLIOSim | Microsoft | Simulates SQL I/O patterns |
Estimating configuration storage and IOPS requirements
The SharePoint configuration database and Central Administration content database have meager storage requirements. Both databases use a negligible amount of space; you can safely plan for roughly 2 GB of configuration database storage and 1 GB of Central Administration content database storage. The configuration database will continue to grow over time, albeit in a very limited fashion (approximately 40 MB per 50,000 site collection.)
Estimating service application storage and IOPS requirements
Service applications vary wildly in the amount of storage and IOPS that they require. The largest consumer of service application resources is search, consuming the lion’s share of available storage and IOPS resources. At the other end of the scale are the State, Word Automation, and PerformancePoint Service applications, each of which requires minimal IOPS and approximately 1 GB of allocated storage.
Table 2 shows a listing of each service application database and the given requirements.
Your environment may host multiples of the databases that display an asterisk (*). TABLE 2 Service application storage and IOPS requirements
| Service Application | Databases | Database Size (Approx.) | IOPS |
| Search | Search Admin | 10 GB | Negligible |
| Search | Crawl (*) | .046 * total size of content databases | 3,500 to 7,000 IOPS |
| Search | Property (*) | .015 * total size of content databases | 2,000 IOPS |
| User Profile | Profile | 1 MB per user profile | Not specified |
| User Profile | Synchronization | 630 KB per user profile | Not specified |
| User Profile | Social Tagging | 0.009 MB per tag, comment, or rating | Not specified |
| Managed Metadata | Managed Metadata | Not specified | Not specified |
| Web Analytics | Staging | Not specified | Not specified |
| Web Analytics | Reporting | Not specified | Not specified |
| Secure Store | Secure Store | 5 MB per 1,000 creden- tials | Minimal |
| State | State | 1 GB | Minimal |
| Word Automation | Word Automation | 1 GB | Minimal |
| PerformancePoint | PerformancePoint | 1 GB | Minimal |
Estimating content database storage and IOPS requirements
In any SharePoint farm, the largest allotment of storage space is for the content. Every list, library, photo, media item, and more are all stored in one or more content databases. Effectively sizing these databases can be difficult, but building rough estimates for provisioning storage and then adjusting these estimates as demand increases is not difficult.
There is a formula that can be used to predict the amount of space required for any given database. Following is a description of the variables and their respective descriptions:
| D The expected number of documents in a content database |
| S The average size of the documents to be stored |
| L The number of list items (roughly three times the number of documents) |
| V The number of retained versions for a document; the default value is 1 for the document |
| M The estimated amount of metadata (a constant of 10 KB that can be adjusted if your environment is more metadata-intensive) |
An estimate for the size of any given content database is the given by this formula:
Database Size = ((D * V) *S) + (M * (V * D)))
Using this formula to analyze the potential size of a content database with the following:
- 50,000 documents (D) expected
- 1,000 KB per document (S) average
- 10,000 list items (L) expected
- Five previous versions of a document (V) expected
This renders a maximum content database requirement of roughly the following:
((50000 * 5) * 1,000) + (10 * (5 * 50,000)) = 250 GB in size
This value should definitely be considered the “maximum” value because SharePoint 2013 stores the delta (changes) between versions of a document.
