One TechNet article I’m always dipping into for reminders when designing SharePoint solutions is the capacity management article defining boundaries, thresholds and supported limits for sites, lists and libraries. For the full article, read SharePoint 2010 Capacity Management: Software boundaries and limits (at time of writing, updated 14 July 2011 following changes introduced with Service Pack 1).
First up, Microsoft definitions:
- Boundary = static limit that cannot be exceeded by design
- Threshold = configurable limit that can be exceeded to accommodate specific requirements
- Supported = Configurable limits that have been set by default to a tested value.
Second, there have been a lot of changes introduced following Service Pack 1 released in June. The last major update to the software boundaries and limits was September 2010. These tables have been updated to reflect the changes.
What follows is my summary and additional notes with references at the end. Some items are in a different order to the key reference as I’ve organised by layer – web app – content DB – site collection – site – list/library – page followed by some of the key services. Note: When a Max.Value has an asterisk next to it, that usually means you’ll never (or shouldn’t, IMHO) get close to it…
Farms and Web Applications
| What | Max. Value |
Limit Type |
Notes |
| Zone | 5 per web app |
Boundary | Hard-coded – Default, Intranet, Extranet, Internet and Custom (just labels, can use for different purposes if needed) |
| Managed Path |
20 per web app |
Supported | Cached on web server so can affect web front-end performance. You normally get 2 by default in your first web app: ‘sites’ and ‘my’. ‘My’ should be in a separate web app if you have more than 100 users or allow large mysites. |
| Solution cache size |
300MB per web app |
Threshold | Allows InfoPath Forms service to hold solutions in cache to speed retrieval of data. If exceeded, solutions are retrieved from disk which may slow response times |
| Application Pools |
10 per web server |
Supported | Limit depends on RAM allocated to web servers and workload of the farm (user base and usage characteristics – a single highly active application pool can reach 10GB or more) |
| SharePoint Entities with Web Analytics enabled | 30,000 per farm | Supported | Do not enable web analytics if a farm is going to contain more than 30,000 entities: includes all web applications, site collections and sites. |
| Office Web Application Cache | 100GB | Threshold | Space available to render documents, created as part of a content database. Not advised to increase this default. Note: it will drop itself in the first site collection. Can use PowerShell to manage. Don’t have it in a busy or important site collection. |
Content Databases and Site Collections
| What | Max Value |
Limit Type |
Notes |
| Number of Content DBs |
300 per web app |
Supported | Increasing the number of content DBs doesn’t affect end user ops but will affect admin such as creating new site collections. |
| Content DB size - General usage |
200GB | Supported | Limit to 200GB for active site collections and general usage scenarios – i.e. collaborative working, search etc. If using remote blob storage (RBS), total volume of remote BLOB storage and metadata in content database must not exceed 200GB |
| Content DB size - All usage |
4 TB* | Supported | Big change with Service Pack 1, previous limit was 1TB and only for archiving/records management – see next row for that scenario. Can now go beyond 200GB for any scenario provided you meet certain criteria, including figuring how you are going to backup and restore in a timely fashion because the cheap methods won’t work. Recommends still keeping site collections to 100GB. Disk sub-system performance must be 0.25 IOPs per GB, prefer 2 IIOPs per GB = expensive… If refactoring site collections, stick to the 200GB limit for content DBs. |
| Content DB size - Archiving |
No explicit limit* | Supported | Previously 1TB. Updateed with Service Pack 1. Read Microsoft’s guidance before considering adopting this approach (links at the end of this post). Sites must be based on Document Center or Records Center site templates. (But no longer specifies only 1 site) Less than 5% of content accessed per month and less than 1% modified or written per month. No alerts, workflows, item level security (but can use Content Routing workflows to get content in) |
| Content DB items or documents | 60,000,000* | Supported | 60 million is the largest numner of items per content database that has been tested on SharePoint 2010. So your 4TB or unlimited Content DB must have less than 60 million items in it.. (items = list items and library documents). |
| Number of site collections |
2,000 rec.* 5,000 max.* |
Supported | The larger the number of site collections in a content database, the slower the upgrade. Limit is linked to size – i.e. must keep within 200GB database limit. 2,000 site collections in a single content DB = 100MB per site collection! Note: if have more than 5,000 users, will need to split MySites (each MySite is a site collection) across more than one contentDB. Easy enough to do, even in Central Admin (just online/offline each DB) but do put them in a dedicated web app. |
| Site Collection size |
Maximum size of the content database*
100GB if using built-in site collection backup/restore |
Supported | This was 100GB pre-Service Pack 1. However Microsoft still strongly recommend keeping the size of site collections to 100GB for two reasons: 1. Certain site collection actions may affect performance or fail if other site collections are active in the content database. (Solution: have 1 site collection per content database) 2. SharePoint site collection backup and restore is only supported for a maximum site collection size of 100GB. If larger, entire content DB must be backed up. If multiple site collections larger than 100GB are in a single content DB, operations may take a long time and fail (Solution: have 1 site collection per content database)
In short: If you have 1 site collection per content database, you can go beyond 100GB. It’s a big leap between 100GB and 4TB/unlimited but 200GB should now be fine. |
| Number of web sites | 250,000 per site collection* |
Supported | Nesting sites is recommended, e.g. shallow hierarchy of 100 sites, each with 1,000 subsites, or a deep hierarchy with 100 sites, each with 10 subsite levels, 100 per level. Both = 100,000. Note: My recommendation: don’t have more than 100 at the top-level… wouldn’t go more than 5 levels deep either – you’ll hit the URL string limit. And I avoid having more than 250 at any level. |
| Subsite | 2,000 per site view |
Threshold | Interface for enumerating subsites of a given web site does not perform well above 2,000. Will also affect All Site Content page and Tree View control. |
| RBS storage subsystem |
20ms | Boundary | If using Remote Blob Storage (RBS), Network Attached Storage (NAS) must respond to a BLOB request within 20ms (i.e. SharePoint must receive first byte from the NAS within 20 milliseconds. For other RBS limits, see also the Content DB size for general usage – RBS deployments must keep the content DB under 200GB. |
| Content deployment jobs running on different paths | 20 | Supported | For paths connected to site collections in the same source content database – exceeding increases risk of deadlocks on the database. If you are using SQL Server snapshots for content deployment, each path creates a snapshot increasing I/O requires for the source database |
Lists and Libraries, Documents and Pages
| What | Max Value |
Limit Type |
Notes |
| List row size | 8,000 bytes | Boundary | Each list or library item can only occupy 8,000 bytes total in the database. 256 bytes are reserved for built-in columns leaving 7,744 bytes to use. The limit includes with row-rapping (a single item can take up to 6 rows to overcome SQL type limits but the list row size must still be less than 8,000 bytes. See notes at the end of this table for designing large lists. |
| Row size limit | 6 table rows | Supported | SQL supports row-wrapping that SharePoint can make use of – it means an item can wrap across up to 6 rows (6 rows required per item) when the number of columns exceed SQL type limits. See notes at the endo fthis table for more details. |
| File size | 2GB | Boundary | Default size is 50MB. Can be increased but other limits will need to be reduced to protect performance (i.e. fewer major versions of documents) Note: All document max. values are based on the default size. Change it and you change the values. |
| Documents | 30,000,000 per library* |
Supported | You will need to nest folders to reach this maximum. The value varies depending on how documents and folders are organised and by the type and size of documents stored. This number can be misleading. See also Major Versions and List View Thresholds – views must return less than 5,000 items. Also, this limit is based on the max. upload size of 50MB. If increase the upload size, reduce the number of documents per library. You still need to consider your chosen content DB limit. If 200GB, that means 400,000 documents based on average file size of 5MB. |
| Major versions | 400,000 per library* | Supported | The number of documents per library includes all versions where version history is used. If 400,000 major versions is the supported limit, then the library supports 400,000 documents from the end user’s perspective (each document is only listed once, regardless of the number of versions behnd it). Actual max. value will depend on your content DB size. If it’s a collaborative site collection with a 200GB limit and you keep 4 versions per document, that’s 50,000 documents, and less if they are larger than 5MB on average. |
| Items | 30,000,000 per list* |
Supported | Note that Microsoft gets around large lists by suggesting the use of views, site hierarchies and metadata navigation to break up large data repositories. See List View thresholds for performance concerns with large lists. |
| Content DB limit | 60,000,000 items or documents |
Limit introduced with Service Pack update. If you have 120 million items, you need 2 content databases, each containing only 2 lists or libraries and nothing else, regardless of the size of the database. | |
| List View threshold | 5,000 items | Threshold | Maximum number of list or library items that a database operation, such as query, can process at the same time outside of daily time window (overnight), when queries are unrestricted. If you want to have a list with more than 5,000 items, you need views that will always return less than 5,000 items. |
| List View threshold for authors and admins | 20,000 | Threshold | The increase above 5,000 for users is possible for auditing so requires appropriate admin permissions – works with the Allow Object Model Override. |
| List View lookup threshold |
8 join ops per query |
Threshold | Maximum number of joins per query, such as lookup columns, person/group columns or workflow status columns. Operation blocks after more than 8 joins, i.e. only see first 8. Doesn’t apply to single item ops. |
| Bulk Operations | 100 items per bulk operation | Boundary | The user interface allows a maximum of 100 items to be selected for bulk operations. If you are using datasheet view and try selecting all, you’ll have problems if all means more than 100 items. Ditto if using the checkboxes instead to select items. |
| Web Parts | 25 per wiki or web part page |
Threshold | Estimate based on simple web parts. Complexity will determine performance e.g. displaying Excel Services or InfoPath forms, connecting Web Parts etc., meaning fewer web parts more likely |
| Coauthoring Office files | 10 recommended 99 maximum |
Threshold | Recommended maximum is 10 concurrent editors per document. Boundary is 99. 100th+ user will get ‘file in use’ error and can only view a read-only copy. Applies to Word (.docx) and PowerPoint (.pptx and ppsx) when authored in Office 2010 (coauthoring not yet supported in browser…) |
Column Limits (Large Lists)
When designing large lists or libraries, consider the following. SharePoint 2010 supports SQL row-wrapping and can wrap up to 6 times (means one item actually occupies 6 rows instead of 1). The maximum size per row is 8,000 bytes, with 256 reserved for built-in columns, which means the total number of user columns must not exceed 7744 bytes, regardless of how many row-wraps are used.
All the following values are Threshold limits.
| Column Type | Per row |
Per list |
Size Bytes |
Notes |
| Singe line of text or Choice |
64 | 276 | 28 | Maximum is capped from 384 due to exceeding 7,744 bytes |
| Multiple lines of text | 32 | 192 | 28 | |
| Number or currency | 12 | 72 | 12 | |
| Date and Time | 8 | 48 | 12 | |
| Lookup, Person or Group | 16 | 96 | 4 | |
| Yes/No | 16 | 96 | 5 | |
| Hyperlink or Picture | 32 | 138 | 56 | Maximum is capped from 192 due to exceeding 7,744 |
| Calculated | 8 | 48 | 28 | |
| Managed Metadata | 14 16 |
94 | 40 32 |
First managed metadata field in a list is allocated 4 columns: tag, string value, catch all and spillover. Subsequent fields have 2 columns: tag and string value. |
| GUID | 1 | 6 | 20 | |
| Int (Integer) . |
16 | 96 | 4 |
External data column typically have a primary column (text field); hidden ID column (multi-line text) and secondary columns (text, number, Boolean or multi-line) based on the data types defined in the BDC.
Tips include creating and using an index to organise a large list – allows filtered views and faster results.
Security
The short version: keep tidy via Active Directory. Put users into Active Directory (AD) groups, put AD groups into SharePoint groups. Don’t forget, you can’t add Sharepoint groups to SharePoint groups.
| What | Max Value |
Limit Type |
Notes |
| Number of SharePoint groups a user can belong to |
5,000 | Supported | Not a hard limit, consistent with AD guidelines. |
| Users (security objects) in a site collection |
2 million per site collection |
Supported | Based on number of entries listed in permissions. Workaround is to use Windows security groups instead of individual users to apply permissions. Also, use Powershell to manage users instead of UI if rendering is slowing down |
| Active Directory Principles/Users in a SharePoint group |
5,000 per group |
Supported | Can have up to 5,000 AD users or groups in a SharePoint group. |
| SharePoint groups | 10,000 per site collection |
Supported | Above 10,000 groups, ops slow down such as adding users to a group |
| Security scope for lists and libraries | 1,000 per list | Threshold | Maximum number of unique security scopes set for a list. Scope contains ACL but can include security principals specific to SharePoint as well as Windows user accounts (i.e. SharePoint groups, Forms-based accounts, AD groups). |
| Security principal: Size of Security Scope |
5,000 per ACL | Supported | Size of scope affects data used for a security check calculation on security principals |
Search
| What | Max Value |
Limit Type |
Notes |
| Search service apps | 20 per farm | Supported | Shouldn’t need more than 20… |
| Content Sources | 50 per search service app | Threshold | The recommended limit of 50 can be exceeded up to the boundary of 500 per search service application if fewer start addresses are used and the concurrent crawl limit must be followed. |
| Start addresses | 100 per content source | Threshold | The recommended limit of 100 can be exceeded up to the boundary of 500 per content source if fewer content sources are used (i.e. less than 50). Ditto for vice versa. Use fewer than 100 start addresses if you have more content sources. Recommended tip if you have lots of start addresses is to use an HTML page containing the start addresses instead – the HTML crawler will then hit the page first and follow the links on the page |
| Concurrent crawls |
20 per search app | Threshold | The number of crawls (content sources/start addresses) that can be underway at the same time. Exceeding will just slow down crawling, defeating the purpose. |
| Crawl rules | 100 per search app | Threshold | Can be exceeded but may struggle to view the rules in search admin UI. |
| Crawl impact rule | 100 per farm | Threshold | Recommendation can be exceeded but display of site hit rules in search admin UI may be affected. At approx. 2,000 site hit rules, the Manage Site Hit Rules page becomes unreadable |
| Crawl DB and Crawl DB items |
10 crawl DBs per search service app25 million items per crawl DB | Threshold | Crawl database stores the crawl data (time, status, etc. ) about all items indexed. Supported limit is 10 crawl database per SharePoint Search service application. Recommended limit is 25 million items per crawl database but at the limit, only 4 crawl database per search service application (due to indexed items limit of 100m per search service app). |
| Crawl components | 16 per search app | Threshold | Require 2 components per crawl database and 2 per server, assuming server has at least 8 cores. Total number per server must be less than 128/(total query components) to avoid performance problems with I/O. |
| Crawl log entries | 100 million per search app | Supported | Number of individual log entries in the crawl log – matches the Indexed items. |
| Indexed items | 100 million per search service application
10 million per index partition |
Supported | Items includes everything that is indexed – people (profile pages), list items, documents, web pages, files |
| Index partitions | 20 per search service app
128 per farm |
Threshold | Each index partition holds a subset of the search service application index. Each partition is recommended to not hold more than 10 million items – i.e. if you have less than 10 million items to index, you only need one partition. Plus at limit, could only have 10 per search app due to Indexed items limit of 100 million. Each partition will also have a property database. |
| Property DBs | 10 per search service app
128 total per farm |
Threshold | Stores the metadata for items in the index partition associated with it. An index partition can only be associated with one property store. (Doesn’t mention if 2 partitions can share a property DB – presumably, given the difference in max. value per search service app). |
| Crawled Properties | 500,000 per search app | Supported | The properties (metadata that goes into the property DB) that are discovered during crawling – i.e. 500,000 equates to 500,000 columns created in the Property DB that contain the metadata. |
| Managed Properties | 100,000 per search app | Threshold | Mapped from crawled properties (for use in queries and scopes) |
| Mappings | 100 per managed property | Threshold | Mappings for each managed property (i.e. mapping the number of crawled properties to a single managed property). Exceeding decreases both crawl speed and query performance |
| Metadata properties recognised | 10,000 per item crawled | Boundary | This is the number of metadata properties that can be determined and indexed when an item is crawled. If you’ve got a content source with more than 10,000 columns, only the contents of the first 10,000 columns will be indexed. |
| Query components | 128 per search app
64/(total crawl components) per server |
Threshold | Total number of query components is limited by the ability of the crawl components to copy files, i.e. query components need to absorb files propagated from crawl components |
| Scopes | 200 site scopes and 200 shared scopes per search service app | Threshold | Exceeding the limit can reduce crawl efficiency (scope membership is determined as items are indexed) and if too many are added to display groups, can affect browser latency for end users. Admin interface will also be affected. |
| Scope rules | 100 per scope
600 total per search service |
Threshold | Exceeding the limit can reduce crawl freshness and delay potential results from scoped queries |
| Display groups | 25 per site* | Threshold | Degrades search admin UI if exceed + assume is per site collection – display groups are only configured as part of site collection admin or in the search site template, not per site for other templates. |
| Alerts | 1,000,000 per search app | Supported | This is the tested limit. Note: you can configure how many alerts an individual can create. The default is 500. |
| Keywords | 200 per site collection | Supported | The boundary (ASP.NET imposed) is 5,000 per site collection given 5 best bets per keyword. Max limit can be modified by tweaking Web.Config or Client.Config files but just don’t |
| Authoritative pages | 1 top level and minimal 2nd and 3rd level per search app | Supported | The boundary is 200 per relevance level per search app but if you add more than a few you’re blurring too much that it’s not going to improve relevance. Stick to 1 for the first level (Note: authoritative pages will add a relevance boost to all content at that link (site in effect). |
| URL removals | 100 removals per operation | Supported | Similar to bulk operation limit in lists – how many URLS can be removed from the index in one go |
User Profiles
| What | Max Value |
Limit Type |
Notes |
| User profiles | 2,000,000 per service app | Supported | If you want to profile more than 2 million people, you’ll need to split into multiple profile services, e.g. Europe, Americas, Asia-Pacific. Exceed 2 million in one profile service app and directory import will likely fail. |
| Social tags, notes and ratings | 500 million per database | Supported | Across all users. Limit is due to concern with backup/restore so if have that solved, can have more. |
Blogs
| What | Max Value |
Limit Type |
Notes |
| Blog posts | 5,000 per site | Supported | Won’t be using SharePoint for busy blog sites then…  Plenty of other reasons not to. For large and public blog sites, using a dedicated tool like WordPress (what this post is being written on) |
| Comments | 1,000 per site | Supported | Techcrunch definitely couldn’t run their site on SharePoint… |
Business Connectivity Services
| What | Max Value |
Limit Type |
Notes |
| ECT (in-memory) |
5,000 per web server (per tenant) |
Boundary | Total number of external content types (ECT) definitions loaded into memory at a given point in time on a web server |
| External system connections | 500 per web server | Boundary | Number of active/open external system connections at a given point in time. Default value is 200. Limit is enforced at the web server scope, regardless of the kind of external system. |
| Database items returned per request | 2,000 per DB connector |
Threshold | Default maximum of 2,000 is used by database connector to restrict the number of results that can be returned per page |
Workflow
| What | Max Value |
Limit Type |
Notes |
| Workflow postpone threshold | 15 | Threshold | Maximum number of workflows allowed to be executing against a content database at the same time, excluding instances that are running in the timer service. When threshold is reached, new requests will be queued to run by the timer service later. |
| Workflow timer batch size | 100 | Threshold | The number of events that each run of the workflow timer job will pick up and deliver to workflows. Configured via PowerShell |
Managed Metadata
| What | Max Value |
Limit Type |
Notes |
| Levels of nested terms | 7 per term store | Supported | Term store hierarchy can have up to seven levels. |
| Number of term sets | 1,000 per term store | Supported | |
| Number of terms in a term set | 30,000 | Supported | Additional labels (synonyms and translations) for the same term do not count. |
| Total number of items in a term store | 1,000,000 | Supported | An item is either a term or a term set. |
PerformancePoint
| What | Max Value |
Limit Type |
Notes |
| Cells | 1,000,000 per query on Excel Services data source |
Boundary | PerfPoint scorecard can’t query more than 1 million cells in an Excel Services Data Source, per query. |
| Columns and rows | 15 columns by 60,000 rows | Threshold | Maximum number when rendering any PerfPoint dashboard object that uses an Excel workbook as the data source. The number of rows can change depending on the number of columns – fewer of one allows more of the other. |
| Query on a SharePoint list | 15 columns by 5,000 rows | Supported | Officially, same as above – fewer columns = more rows. However recommend sticking with 5,000 max – fits the query threshold limit for list views. |
| Query on a SQL Server data source | 15 columns by 20,000 rows | Supported | As with previous – number of rows can change depending on number of columns. |
SharePoint Workspace (formerly known as Groove)
| What | Max Value |
Limit Type |
Notes |
| Synchronisation item limit | 30,000 items per list | Boundary | SharePoint Workspace won’t synchronise lists that have more than 30,000 items due to download time being too long and occupying resources. |
| Synchronisation doucment limit | 1,800 documents in a workspace | Boundary | Users receive a warning when they have more than 500 documents in a workspace. |
Project Server
| What | Max Value |
Limit Type |
Notes |
| End of project time | Date: 31 Dec 2039 | Boundary | Project plans cannot stretch into 2050… draw your own conclusions about that. |
| Deliverables per project plan | 1,500 deliverables | Boundary | |
| Number of fields in a view | 256 | Boundary | |
| Numbr of clauses in a filter for a view . | 50 | Boundary . |
.
Related Blog Posts
References
- SharePoint 2010 Software boundaries and limits – TechNet
- Designing large lists and maximising performance – TechNet
- Data storage changes for SharePoint 2010 (post Service Pack 1) – SharePoint Team Blog
- Techniques for managing large lists – SharePoint help, Microsoft.com
- Managing large lists in SharePoint for users and site admins – Joel Oleson
This post is filed in the Architecture & Planning section of the SharePoint 2010 Handbook on this site.
Thank you for taking the time to write this article. One stop location to research SP list, library, web app, farm etc. capacity. Found this very helpful and am pinning to my favorites. Thanks!
You’re most welcome
It’s certainly save me some time over the projects, hope it does the same for you 