Store your Sitecore Session in SQL instead of Mongo DB

When we rolled out Mongo to power our Sitecore experience database, we thought we'd also use it also for Session storage, because, why not, it's cool, should scale and perform better than other out of process Session storage options. In the past couple of months however, we've seen a few outages due to Mongo being unavailable for short durations. And while we can probably tune and reconfigure things to make that a less likely event, I'm recommending we switch to SQL for session storage.

The simple reason: I rather have have one single point of failure than multiple single points of failure. Think about it. If Mongo goes down, for xDB, Sitecore will gracefully handle it. I think they will even try to queue data and retry when the connection is re-established (to a configurable point of course), but if there are hiccups, your customer experience will not suffer.

But if you're using Mongo for Session, and it becomes unavailable, your sites won't function at all. The Session Provider doesn't handle it as gracefully as xDB does.

So, instead, we're going to move back to SQL as the session provider. Because if SQL goes down, Sitecore won't function regardless and we've got bigger problems to deal with.

Refactoring Sitecore Templates without Losing Data

Handlebar Renderings and Semantic Templates in Sitecore

Handlebar Renderings and Semantic Templates in Sitecore