Sharepoint databases

Sharepoint uses SQL (or MSDE) for its data storage. By default several databases are created. Here is a small summary of the databases and their purpose.

• Configuration database (Default: Sharepoint_Config_db) - In a Windows Sharepoint Services environment, there can be multiple front-end Web servers that contain several websites whose content is stored in one of a number of back-end databases. To keep the front-end Web servers stateless, a centralized database is needed to keep track of which content database holds the data for a specific site. When a front-end Web server receives a request for a page from a site, the first connection it must make is to this configuration database. For performance reasons, this information is cached on the front-end Web servers for subsequent requests and the cached information is used by the front-end Web server thereafter.
  
  During installation Sharepoint Portal Server adds extensions to the configuration database created by Windows Sharepoint Services. These extensions include adding a new schema and modifying tables by adding new stored procedures. This means that WSS cannot connect to a SPS configuration database and vise versa.
  
  There is only one configuration database

• Profiles database (Default: <portalname>1_PROF) - This is the is the profiles database. It contains all the information relating to peoples profiles, including those imported from the AD, and audiences.

• Services database (Default: <portalname>1_SERV) - This database stores component settings in order to provide services to the Sharepoint Portal Environment. It contains alert definitions, notifications and the gatherer logs. Also called component settings database.

• Content database (Default: SPS <portalname>1_SITE, WSS STS_<machine name and guid>) - This is the content database for a given virtual server. By default it contains all the portal and team site information including documents and lists.
  
  Content databases provide content to the front-end Web servers when it is requested. All site content -including site documents, list data, Web Part properties, as well as user names and rights- are stored in the content databases. You can create as many content databases as needed to support the websites on your server. This can range from just one to thousands, depending on the number of users.