What follows is adapted and taken almost directly from this Microsoft Technet post and just formatted into a table
| Descriptor | Size range |
|---|---|
| Very Small | Up to 100 megabyte (MB) |
| Small | 1 gigabyte (GB) or less |
| Medium | Up to 100 GB |
| Large | Up to 1 terabyte |
| Extra-large | More than 1 terabyte |
The database names are what will happen if you use the psconfig wizard to create a 2013 farm
Under each DB name is the description from Technet.
| Default name
DB Description |
Location Requirements | Size info \ growth factors | R\W Characteristics | Recommendation for scaling | Associated health tasks | Supported backup tools | Default recovery model | |
| SharePoint_Config | Co-located with Admin DB | small, T-logs are likely to get big | Read-intensive | Must scale up because only one config per farm, it is unlikey that this db will get large | None | It is recommended to backup the T-logs regularly to force truncation. If mirroring, microsoft recommends database be in full recovery mode. The | Full. MSFT recommends switching to Simple to restrict growth of the log file | |
| The configuration database also contains specific data for SharePoint 2013 farm settings, such as default quota settings and blocked file types. | ||||||||
| SharePoint_AdminContent_GUID | Co-located with Config DB | Small, If you use Power Pivot for SharePoint 2013 and use the default usage data collection and data refresh for 365 days the central admin db will grow over the span of one year. | Varies | Must scale up because only one admin per farm, significant growth is not likely | None | SharePoint 2013 backup and restore, SQL Server, and SCCM 2012 – DPM. Backup and restoring the Admin db requires the farm to be offline on the restore, see technet for more details. | Full | |
| The Central Administration content database is considered to be a configuration database. It stores all configuration data for the Central Administration site collection. If SQL Server 2012 Power Pivot for SharePoint 2013 is installed, the Central Administration content database also stores the Excel worksheets and Power Pivot data files used in the Power Pivot Management Dashboard. Note that Power Pivot for SharePoint 2013 can only be installed on SharePoint Server 2013. | ||||||||
| WSS_Content | None | MSFT recommends keeping it under 200 GB, although content DB’s up to 1 TB are supported for large, single-site repositories and archives which remains reasonably static and use either the Record Center or Document Center template, for more info check out https://technet.microsoft.com/en-us/library/cc298801.aspx. Growth factors for collaborative sites include: Number of Documents, Users, use of versioning, use of Recycle Bins, size of quotas, whether audit trail is configured, and how many items are chosen for auditing, check that link for detailed advice on how to plan for growth of content db’s | Varies – Collaborative are write intesive; whereas document management environments are read-intensive | Must scale up. You can move site collections out of a content db into another cdb under the same web app to save space and keep db’s lower than 200 GB | None | SharePoint 2013 backup and restore, SQL Server, and SCCM 2012 – DPM. | Full | |
| Content databases store all content for a site collection. This includes site documents or files in document libraries, list data, Web Part properties, audit logs, and sandboxed solutions, in addition to user names and rights.
All of the files that are stored for a specific site collection are located in one content database on only one server. A content database can be associated with more than one site collection. Content databases also store user data for Power Pivot for SharePoint, if you installed it in your SharePoint Server 2013 environment. Note that Power Pivot for SharePoint can only be installed on SharePoint Server 2013 |
||||||||
| AppManagement | None | Small, scale up when db reaches 10 GB. Scale out only on SharePoint Online | Write-Heavy during apps installation and license renewal | App license management can scale out only on SharePoint Online | None | SharePoint 2013 backup and restore, SQL Server, Windows PowerShell, and SCCM 2012 – DPM. | Full | |
| The App Management database is used by the App Management Service application. It stores the app licenses and permissions that are downloaded from the SharePoint Store or App Catalog. | ||||||||
| Bdc_Service_DB_GUID | None | Small. Size is determined by the number of connections. | Read-heavy | Must scale-up. The database must grow larger, because only one Business Data Connectivity database is supported per farm. (Significant growth is unlikely.) | None | Same as above | Full | |
| The Business Data Connectivity service application database stores external content types and related objects. | ||||||||
| Search | ||||||||
| Search_Service_Application_DB_GUID | The Administration database should fit into RAM on the server so that the server can handle the end-user query load most efficiently. Because of this requirement, it is usually best not to have the Administration and Crawl databases located on the same server. | Medium. The factors that influence growth include the number of best bets, the number of content sources and crawl rules, the security descriptions for the corpus, and how much traffic. | Equal read/write ratio | Scale-up the database that supports the service application instance. Scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | Same as above, and The backup and restore process for all Search service application databases with SQL Server tools is limited to the following specific scenarios:
Backup and Restore of the Search Administration database can be done for configuration migration or upgrade activity. Perform a backup and restore of Search service application databases only when the SharePoint farm is fully stopped. When the SharePoint farm is stopped you can back up the farm to snapshots or make a backup with SQL Server tools to ensure the search indexes are synchronized with the search databases. Note that a restore must include all of this backup set. We do not support restoring search database backups that are not synchronized with the search indexes. This might result in unexpected search experiences and has a high risk of search index corruption. You should perform all database backups within the same time frame to avoid databases that are out of sync with each other. |
Simple | |
| The Search Administration database hosts the Search service application configuration and handles crawl state orchestration, including the content source crawl history. | ||||||||
| Search_Service_Application_AnalyticsReportingStoreDB_GUID | None | Medium to large. | Write heavy during nightly analytics update. | Scale out by creating additional Analytics Reporting database using a split operation when the main database becomes >200 GB. | None | SharePoint 2013 backup and restore, Windows PowerShell, and SQL Server. | Simple | |
| The Analytics Reporting database stores the results for usage analysis reports and extracts information from the Link database when needed. | ||||||||
| Search_Service_Application_CrawlStoreDB_GUID | None | Medium | Read heavy | Scale out by creating additional Crawl database per every 20 million items crawled. | None | Same as above | Simple | |
| The Crawl Store database stores the state of each crawled item and provides the crawl queue for items currently being crawled. | ||||||||
| Search_Service_Application_LinkStoreDB_GUID | We recommend that if you have sites that have heavy traffic, the Link database should use separate spindles from other databases. | Medium to Large. The Link database grows on disk by 1 GB per 1 million documents fed. The click through data grows linearly with query traffic, 1 GB per million queries. | Write heavy during content processing. | Scale out by creating additional Link database per every 60 million documents crawled. Also add additional Link database per 100 million expected queries per year. | None | Same as above | Simple | |
| The Link database stores the information that is extracted by the content processing component and the click through information. | ||||||||
| Secure_Store_Service_DB_GUID | For secure credential storage, MSFT recommends that the Secure Store database be hosted on a separate database instance or database server that has access limited to one administrator. By default, if the database is hosted on the default SharePoint database server and instance, all database administrators will have access to the Secure Store database. | Small. Size and growth are determined by the number of target applications, number of credential fields per target application, and the number of users stored in each target application. If auditing is turned on, the number of read and write operations performed against a given target application also affects size. | Equal read/write ratio | Scale-up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | Same as above | Full | |
| The Secure Store Service application database stores and maps credentials, such as account names and passwords. | ||||||||
| SharePoint_Logging | The Usage and Health Data Collection database is very active, and should be put on a separate disk or spindle, if it is possible. | Extra large. Database size depends on the retention factor, number of items enabled for logging and external monitoring, how many Web applications are running in the environment, how many users are currently working, and which features are enabled. | Write-heavy | Must scale-up. That is, the database must grow larger, because only one Usage and Health Data Collection service application instance is supported per farm. | None | Windows PowerShell and SQL Server | Simple | |
| The Usage and Health Data Collection database is used by the Usage and Health Data Collection service application. It stores health monitoring and usage data temporarily, and can be used for reporting and diagnostics. The Usage and Health Data Collection database is the only SharePoint database that supports schema modifications. | ||||||||
| SettingsServiceDB | None | Small. Size is determined by the number of tenants, farms, and features supported. | The subscription database is read-heavy. | Scale-up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | SharePoint 2013 backup and restore, Windows PowerShell, and SQL Server. | Full | |
| The Microsoft SharePoint Foundation Subscription Settings service application database stores features and settings for hosted customers. The Subscription Settings service application and database are not created by the SharePoint Products Configuration Wizard — they must be created by using Windows PowerShell cmdlets or SQL Server. For more information, see New-SPSubscriptionSettingsServiceApplication | ||||||||
| User Profile Databases | ||||||||
| User Profile Service Application_ProfileDB_GUID | None | Medium to large. Growth factors include additional users and the use of news feeds. News feeds grow with user activities. The default is to maintain the last two weeks of activity, after which a time job deletes the news feed items older than two weeks. | Read-heavy | Scale-up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | Same as above | Simple | |
| The Profile database stores and manages users and associated information. It also stores information about a user’s social network in addition to memberships in distribution lists and sites. | ||||||||
| User Profile Service Application_SyncDB_GUID | None | Medium to large. Growth factors include the number of users, groups, and the ratio of users to groups. | Equal read/write ratio. | Scale-up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | Same as above | Simple | |
| The Synchronization database stores configuration and staging data for use when profile data is being synchronized with directory services such as Active Directory. | ||||||||
| User Profile Service Application_SocialDB_GUID | None | Small to extra-large. Growth factors include the number of tags, ratings, and notes that have been created and used. | Read-heavy | Scale-up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | Same as above | Simple | |
| The Social Tagging database stores social tags and notes created by users, alongside their respective URLs. | ||||||||
| WordAutomationServices_GUID | None | Small | Read-heavy, once per conversion item. | Scale-up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements. | None | Same as above | Full | |
| The Word Automation Services database stores information about pending and completed document conversions and updates. The Word Automation Services Timer Job processes and distributes this information as queued conversion job items to application servers. | ||||||||
| Managed Metadata Service Application_Metadata_GUID | None | Medium. Growth factors include the amount of managed metadata. | Read-heavy | Scale-up the database that supports the service application instance. Scale out by creating additional instances of the service application | None | Same as above | Full | |
| The Managed Metadata service application database stores managed metadata and syndicated content types. The Taxonomy service works in conjunction with the Managed Metadata Service that provides the Term Store Management Tool in the SharePoint Central Administration website. This means that the Managed Metadata service application database stores the metadata for the Taxonomy service. The Taxonomy service metadata is stored in a hierarchical structure for items that are used for tagging content and building site collections. | ||||||||
| SharePoint Translation Services_GUID | None | Small | Read-heavy | Scale-up the database that supports the service application instance. Scale out by creating additional instances of the service application | None | Same as above | Full | |
| The Machine Translation Services stores information about pending and completed batch document translations with file extensions that are enabled | ||||||||
| Project Server | ||||||||
| ProjectWebApp | None | Small to medium. | Read-heavy | Scale-up the SQL Server that hosts the Project Web App database. (Significant growth is unlikely.) | None | Same as above | Full | |
| Project Server creates a separate database for each instance of Project Web App. Each Project Web App database contains the following data:
All Project and Portfolio Management (PPM) data Time tracking and Timesheet data Aggregated SharePoint project site data |
||||||||
| SQL Server Power Pivot Service service application database | ||||||||
| DefaultPowerPivotServiceApplicationDB_GUID | None | Small | Read-heavy | Scale-up. (Significant growth is unlikely.) | None | Same as above | Full | |
| The Power Pivot Service database stores data refresh schedules, and Power Pivot usage data that is copied from the central usage data collection database.
SQL Server 2012 Power Pivot for SharePoint 2013 requires SQL Server 2012 Analysis Services (SSAS), Business Intelligence or Enterprise edition. When being used, Power Pivot stores additional data in content databases and in the Central Administration Content database (WSS_Content). |
||||||||
| PerformancePoint Service _GUID | None | Small | Read-heavy | Scale-up the database that supports the service application instance. Scale out by creating additional instances of the service application | None | Same as above | Full | |
| The PerformancePoint Services database stores temporary objects and persisted user comments and settings. | ||||||||
| SessionStateService_GUID | None | Medium to large, depending on usage of features that store data in the State Service database. | Read-heavy | Scale out by creating another State Service database with Windows PowerShell cmdlets. | None | Same as above | Full | |
| The State Service database stores temporary state information for InfoPath Forms Services, Exchange Server, the chart Web Part, and Visio Services. | ||||||||
| SQL Server System Databases | ||||||||
| master | The master database must be located on the same SQL Server instance that SharePoint uses. | Small | Varies | Scale-up. (Significant growth is unlikely.) | None | SQL Server backup and restore. | Simple | |
| The master database records all the system-level information for a SQL Server instance. This includes logins, configurations, and other databases. | ||||||||
| model | The model database must be located on the same SQL Server instance that SharePoint uses. | Small | Varies | Scale-up. (Significant growth is unlikely.) | None | SQL Server backup and restore. | Simple | |
| The model database is used as the template for all databases created on the SQL Server instance. Any modifications made to the model database are also applied to all databases created afterward. | ||||||||
| msdb | The msdb database must be located on the same SQL Server instance that SharePoint uses. | Small | Varies | Scale-up. (Significant growth is unlikely.) | None | SQL Server backup and restore. | Simple | |
| The msdb database is used by SQL Server Agent for scheduling alerts and jobs. | ||||||||
| tempdb | Locate on a fast disk, on a separate spindle from other databases. Create as many files as needed to maximize disk bandwidth. Using multiple files reduces tempdb storage contention and yields significantly better scalability. However, do not create too many files because this can decrease performance and increase management overhead. As a general guideline, create one data file for each CPU on the server and adjust the number of files up or down as necessary. Note that a dual-core is two CPUs. | Medium, depending on activities such as how many users are using the system, in addition to the specific processes that are running. For example, online rebuilds of large indexes, or large sorts cause the database to grow quickly. | Varies | Scale-up. (Significant growth is unlikely.) | None | SQL Server backup and restore. | Simple | |
| The tempdb database holds temporary objects or intermediate result sets. For example, it holds all temporary tables, temporary stored procedures, and any other temporary storage needs. The tempdb is recreated every time SQL Server starts. | ||||||||
| SQL Server Reporting Services | ||||||||
| ReportingService_GUID | Must be located on the same database server as the ReportServerTempDb database. | Small | Read heavy | Scale-up. (Significant growth is unlikely.) | None | SQL Server backup and restore. | Full | |
| The SQL Server Reporting Services Report Server Catalog database stores all report metadata including report definitions, report history and snapshots, and scheduling information. When Report Server Catalog is used, report documents are stored in SharePoint content databases. | ||||||||
| ReportingService_GUID_TempDB | Must be located on the same database server as the Report Server Catalog database. | This database size varies and goes from small to extra-large frequently. The size depends on use of cached report snapshots. | Read heavy | Scale-up the database. | None | SQL Server backup and restore, but we do not recommend that you back up this database. | Full | |
| The SQL Server Reporting Services ReportServerTempDB database stores all the temporary snapshots while reports are running. | ||||||||
| ReportingService_GUID_Alerting | Must be located on the same database server as the Report Server Catalog database. | This database size varies and goes from small to extra-large frequently. The size depends on use of Data Alerts. | Equal read heavy and write heavy. | Scale-up to optimize the file I/O and memory usage. | None | SQL Server backup and restore. | Full | |
| The Report Server Alerting database stores all Data Alerts metadata and runtime information that is required to produce Data Alerts for Reporting Services operational reports. Data from reports is processed in the database to match rules that are defined in Alert Definitions | ||||||||