I Found a Good Use Case for MongoDB

The year was 2012. One of my newfound mentors was talking about how their company was adopting it and how exciting it was. Two weeks later, a follow up email told me the whole company was going down in flames.

Obviously, that company didn't close up shop because it thought Mongo was a good idea. But that story would lay the foundation in my brain for what Mongo is good for. My teammates at Viget would go on to use MongoDB on a few client projects and complain about it's various shortcomings. We love our relational databases, our foreign key constraints, our well organized schemas that stand as the architecture for The Truth. As time went on, the internet seemed to agree:

Why keep your data organized when you can just throw it on the floor?

8 Years Later... #

I found myself as the sole developer tasked with migrating thousands of records from one loosely structured content management system (CMS) to another. Thankfully, both CMS frameworks understood JSON. I could pull JSON data out of the old system, and import JSON into the newer one. Easy peasy.

Until, of course, the business logic entered the process and it turned out there needed to be roughly 2 dozen modifying procedures that fiddled with the data while it was in transit. Tasks such as the tying up of Press Release authors with database-backed Staff members, or removing the 5,000 <ul> tags that needlessly wrapped 5,000 <a> tags. Some tasks were big, some were small, some touched one data type, some touched all of them, some had to be run before others.

It quickly grew out of hand, and my initial attempt at the simplest thing that could work was breaking down. The deadline getting ever closer. I needed a database, and I needed it now. The usual tools in my toolbox (PostgreSQL, Ruby + ActiveRecord) were a little daunting however. I wanted my database to be all of these things:

• Easy to spin up
• Easy to blow away and recreate
• Easy to add new tables
• Easy to add new fields
• Easy to change the types of existing fields

Relational databases, with their schemas, require that any changes to the data structure be done using a migration. While it would have been very possible to pull in Postgres, I felt there was something better out there. Something that was more flexible, infinitely flexible even. And then, in the middle of the night, it came to me:

MongoDB was Perfect #

Theoretically, what I needed was a thin wrapper on a bunch of JSON files. I wasn't starting a new company that needed to survive for years to come, I was organizing data for a few weeks before never thinking about it again. And Mongo delivered.

Adding a new "table" with all of its fields was as easy as adding a new Ruby file that described the table. To add a new field to an existing table, I simply added a new line describing that field. To update a field, I just changed the field's type declaration. Mongo doesn't care that the new type might be incompatible with existing data, and neither do I!

Fare thee well ye olde data migrations

This newfound flexibility meant that I was able to reap all of the benefits that a database provided (persistent data storage, organized Ruby classes surrounding each data type), but gave me the flexibility to do just about whatever I wanted with that data.

And, thanks to the Mongoid gem, I was able to query against the data using familiar ActiveRecord-like syntax, and with reasonable performance. If I blurred my eyes a bit through that part, you could hardly tell that your database was an unorganized jumble of arbitrary characters with no referential integrity.

Would I Reach for Mongo in the Future? #

If I find myself in a similar boat (migrating large amounts of data), I would certainly consider it. MongoDB brought organization to my sprawling application, and let me organize the data structures I needed with great speed. All of the benefits of a database, but without a lot of the drawbacks.

I can see now, maybe, why the hype wave was so large back in 2012. The world of database management is deep and daunting, and there's no end to the knowledge you can acquire in regards to organizing one properly. If "rapid prototyping" was your thing, I can see the appeal: MongoDB let me get up and running quickly, and let me change course whenever I wanted at the drop of a hat.

That said, my use case was short term, and no one really cared what the data looked like under the hood; so long as it ended up in the right place with the right content the team was happy.

Strong opinions, loosely held.

An old mentor of mine used to say this all the time. I think I'm a little closer to understanding it now. And I have MongoDB to thank for that.