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