Noah Coad

Our team has decided to use MongoDB for the next generation of our platform’s health record storage. We believe Mongo’s dynamic approach will be a big plus and velocity gain. There are a number of factors that went into the overall decision, but pros that that stood out for us were:

1. It excels where adding new schema is a common activity.  We expect to be updating our schema to add fields on an almost daily basis.  We will have a significant amount of ‘dynamic schema’ where each record has a common set of schema, as well as schema unique to a specific record.
2. Deployment of schema additions with SQL from development to production can be painful, but isn’t an issue with Mongo.  Got schema additions?  Mongo just don’t care.
3. Our system typically needs to work with an entire health record at once.  A hieratical tree view of the data works well.  It is very fast to retrieve the entire data structure, make updates entirely in memory, and push it all back.   We don’t need to worry about the number of joins between tables that can drastically slow down working with SQL (without additional effort to optimize).
4. Our internal data model and repository pattern is still fairly infrastructure agnostic, so if we did need to move to SQL someday it’s a possibility without significant code re-write.

We understand there are real-limitations, but thankfully not ones we believe will be deal-breakers, or really affect us in the foreseeable future (applying YAGNI here).  It is entirely new for our development team, so there’s ramp-up time involved instead of going with the ‘tried and true’.  With these said, we expect it to still be a big productivity boost.  This is just the beginning of our journey.  I’m looking forward to seeing how this progresses in the next few months.

Update (2/1/2013): I’ve added a video: 3 Step Intro to MongoDB for .NET in 15min