What is the difference between Sitecore's core, master, and web databases?

Question

What is the difference between Sitecore's core, master, and web databases?

Wow

Answer 1

I recommend you look at the Launch Sitecore site to understand more about the CMS.

From the page on Sitecore Architecture:

Master

The Master database is the authoring database - it contains all versions of any content or assets.

Core

The Core database is all Sitecore settings, as well as the tables containing the .Net membership provider (i.e. users/roles contained in the Sitecore repository)

Web

The Web database is only the latest published version, and the content that is driving the live web site. Therefore it is a subset of the master database, optimised for size and speed. When content is published, or goes through the publishing task of a workflow, the latest content version is copied from the master to web database.

Of course, in an Enterprise deployment, you may have multiple Sitecore instances, which may share DBs (or not)

Radiotherapy

Good link, but I disagree with the description for Core. "All Sitecore settings" is much too broad a statement. Most run-time settings are stored in the context database /sitecore/system hierarchy. – Mach

Agreed. Launch Sitecore is a site by Sitecore, so perhaps let them know. – Radiotherapy

Sitecore v 8.0 and upwards store multiple versions of an item in the web database if multivariate tests are using these versions. – Randolphrandom

Answer 2

• Master: Contains all versions of all items. This is the database that content authors interact with, and is the default database used by the Sitecore Content Ediitor.
• Web: This contains only the current versions of items. This is the database that supports the live website.
• Core: This database has two purposes:
  1. It contains definitions for the Sitecore user interface (Content Editor, Page Editor, etc.). This is where you would go to add, for example, a new Right-click option to the Content Editor or a new ribbon button to the Page Editor.
  2. It contains the ASP.NET membership tables that drive authentication and security.

Mach

Isn't it kinda slow to separate content, from content types (and templates) and especially if the content is protected to certain users/roles then before rendering content, they'd have to do cross database join between core (user/membership), web (content) and in worst case they'd have to join the Reporting database for personalized content rendering based on which contact, right? Wouldn't it have made more sense to use schemas for separation and use less databases for performance reasons? – Obsess

Answer 3

Some great answers here but it's worth a clear note that the Web database is the default publishing target and is not set in stone. You can rename it to whatever you wish as well as have multiple publishing targets similar to 'Web'.

e.g. We have a Sitecore instance with two websites (website and intranet), thusly the Master database contains all the items for both sites. For publishing we have two targets 'Website' and 'Intranet' that are hosted by different SQL servers.

Ultimately our connections include: Core; Master; Website; Intranet (the latter two being copies of the original 'Web' database of course)

Kalmuck