The Experience Database in Sitecore is one of the platforms most differentiating features over its competitors in the Web Content Management System space.  It stores all analytics and interaction data for users across all of your digital properties, whether those users are known or anonymous.

From the documentation:

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.

History of xDB - a look back

When xDB was launched with Sitecore 7.5, the contact and interaction model was architected around web interactions.

Everything centered around the fact that a user, or Contact, was interacting with your brand on the web. A Contact had multiple Interactions and those interactions held a collection of Pages that had been visited. Those pages then held any Page Events, Goals or Outcomes that had been triggered. If you wanted to do anything with external data, track any type of offline interactions, you could certainly do it. However, it was fairly hacky. You had to create a fake Page to hold the event, goal or outcome, just to add it to the interaction.

Also, because everything was architected around web interactions, all data flowing in to and out of xDB had to go through a full, kernel-based Sitecore instance.

So, what is xConnect?

Simply put, xConnect abstracts the storage architecture and internal services used by xDB away from any client, including Sitecore.

Here's an illustration of xDB from Sitecore 7.5-8.*:

As you can see, there were many pieces of the Sitecore platform that depended directly on the Collections database. Any software architect worth his or her salt understands that this is a recipe for disaster!

With the introduction of Sitecore 9 and xConnect, that picture looks more like this:

Any data flowing in to and out of xDB now flows through xConnect! The storage architecture is now wholly irrelevant to anyone collecting, retrieving or searching for xDB data.

And since Sitecore went to all the trouble of abstracting away the storage architecture, why not remove one of the largest barriers to adoption of Sitecore and xDB at the same time? In Sitecore 9, the default data provider for the Collections database in xDB is now SQL Server 2016, not MongoDB! Yes, you read that correctly!

Don't worry, MongoDB will still be supported. In fact they're even going to be adding official support for Cosmos DB in a future release as well, as another NoSQL storage option.

Collection model changes

As I mentioned earlier, the collection model in previous versions of xDB revolved around web interactions. In Sitecore 9, the collection model has changed slightly, enabling it to be more flexible and provide better support for non-web-based interaction data.

Now, a Contact holds a collection of Interactions. Each interaction contains a series of events. That's it! So no more "fake pages". :)

Integrating external data into xDB

Since xConnect is now available as a kernel-less, stand-alone service, any client can now search, retrieve or insert data into xDB. IoT devices, console applications, kiosk applications, beacons - any type of 3rd party data from any type of client. This finally enables truly-native, omni-channel data collection at scale.

So, what does it look like to work with the xConnect client? Check out these posts to learn more:

• Creating a Contact using xConnect
• Adding custom facets with xConnect
• Searching for Contacts using xConnect
• Adding events and interactions to a Contact using xConnect

Happy Sitecore trails, my friend!