Architecture overview
A high level description of the Sitecore Experience Database
The Sitecore Experience Database (xDB) collects all your customer interactions from all channel sources in a real-time, big data repository. It connects interaction data to create a comprehensive, unified view of each individual customer, and makes the data available to marketers to manage the customer experience in real time.
The xDB architecture is flexible allowing you to deploy single-server, low-traffic solutions as well as highly scalable, high-traffic, multi-server, solutions.
The key architecture components in the xDB are:
Content delivery server (including personalization)
Content management server
Content databases (SQL Server)
Session state server
Collection database (MongoDB)
Processing server
Reporting database
Reporting service
Content delivery server and personalization
You can implement content delivery and personalization using a Sitecore application server that serves incoming HTTP requests for website content from the Internet.
Content management server
Content management in this document refers to the core functionality of Sitecore such as authoring and editing content, managing content, and configuring your website solution.
CMS databases (SQL Server)
Sitecore CMS uses the following three SQL Server databases:
Core – contains all settings, like a large configuration file for the Sitecore user interface. You can use this if you are customizing Sitecore, for example, by adding new applications to the Sitecore desktop.
Master – contains all versions of all content. This is where business users author and edit content.
Web – contains the latest version of published content that has reached a final workflow state.
Session state server
The session state component is a session state store used by the content delivery and personalization process. This is a standard ASP.NET session state store provider that includes support for the Session_End
event. In Sitecore xDB, the default session state provider is inProc
ASP.NET but it also comes with providers for Redis, MongoDB, and SQL Server.
Collection database (MongoDB)
The collection database (MongoDB) is the primary storage for all analytics information and the registry of contacts and engagement automation states. It uses MongoDB – a highly scalable document-based NoSQL database solution.
Processing server
The processing and aggregation component extracts information from captured, raw analytics data and transforms it into a form suitable for use in reporting applications. It also performs specific tasks on the collection database that involve mass updates.
You implement processing and aggregation on a Sitecore application server connected to both the collection and reporting databases. A processing server can run independently on a dedicated server, or on the same server together with other Sitecore components. By implementing multiple processing or aggregation servers, it is possible to achieve higher performance on high-traffic solutions.
Reporting database
The reporting database is a SQL Server database that stores aggregated data from the collection database suitable for fast querying and reporting.
Reporting service
The Reporting Service API allows you to execute queries and extract information from the collection and reporting databases. It is a part of the xDB but you can also configure the Reporting Service as an intermediate reporting server which performs processing tasks and offloads endpoint application servers.
Note
The database names collection and reporting are not official Sitecore product names.
The collection database refers to the functionality and purpose of the MongoDB analytics database.
The reporting and reporting.secondary databases correspond to the SQL Server Sitecore_Analytics and the Sitecore_Analytics_Secondary databases. These are legacy names that continue to be used.
Diagram showing a simplified version of the xDB architecture
![]() |
When a contact interacts with your website, the xDB collects all contact and the interaction data. This data flows through the xDB in the following sequence:
A contact decides to interact with a website.
Depending on the geographic location of the contact, the xDB redirects their visit to the closest cluster (data center) through DNS configuration.
Load-balancing software directs the contact to an appropriate Sitecore content delivery server. Contacts stay connected to the same cluster even if they switch devices or use another browser. Contacts can only move to another cluster if all their active sessions expire and all their information is then saved to the collection database.
During the session, details of the contact, the interaction, and the device are stored in either a private or shared session state. On session end, Sitecore flushes this data to the collection database and schedules it for processing.
The processing layer reduces and groups interaction (online visit) data and stores it in the reporting database for use by the reporting layer. This is known as aggregation. Data is also aggregated by the processing layer for use by the segmentation index.
The Reporting Service queries the reporting database to fetch reporting data for use in applications such as Experience Analytics (xAnalytics).