In this tutorial, you will learn a little more about SiteCores database architecture. Like every other CMS on the planet, Sitecore's data is stored in a database. Where Sitecore differs from a lot of other CMS systems, Sitecore makes use of multiple databases. If you look at your SQL server after you install a fresh copy of Sitecore, you should see something like this:
This may seem like a lot of databases for a single CMS, however, each database has its own specific purpose. The CMS uses three databases to store content. These are called core, master and web. Let us quickly drill into what each one is used for:
Core: As the name implies, this is where the core Sitecore items and associated data are stored. Tables like the .Net membership provider tables are stored here.
Master: This database is used to store all the authoring objects.
Web: This is where the production website data will be stored. When you want a page to go live, you will promote it from the master database and move it into the web database. Splitting up the database between master and web has a few benefits. The first is security, only having public-facing data in the database means that you are not exposing any internal or secure data to the world. The second is performance. As the web database will have a smaller subset of objects, data retrieval will be quicker.
That covers the three main databases used by the CMS. The eagle-eyed may have noticed a fourth database👁️👁️ in the screenshot above. This fourth database is the analytics database.
Analytics and xDb
Historically, analytics data used to be stored in the main database, however, as of v7.5 this changed. With the release of Experience Database Analytics (xDb) a shift in how data is stored also occurred. Sitecore made a massive jump forward in analytics and personalisation capabilities with xDB. Sitecore can now provide real-time analytics as customers interact with your website, mobile app or email campaign.
This level of instant access wouldn't have been possible with the old SQL database modal. Doing real-time data storage and CMS querying on the same database would have caused too much network load and impact on site performance. To counter this performance bottleneck, Sitecore decided to use a NoSql approach, using MongoDB. If you have never used Mongo before, there's no need to panic.
Mongo is a NoSQL database, which means data is stored on the disk and loaded in memory (unless you go cloud-hosted) rather than a SQL database. NoSQL calls are generally faster than SQL calls. There are numerous NoSQL alternatives, Mongo is not the only one. Redis and Cassandra are other popular NoSQL frameworks.
The xDb data is first stored within the MongoDB database. Mongo is the place to see current/live analytics. After a certain period, this data is then copied into SQL for historic data. The analytics database can then be used to query historical analytic data.
This concludes all the different Sitecore databases. Happy Coding 🤘
