The When & Why for MongoDB

MongoDB has been around since 2007, but has only recently started getting more attention as a viable database solution.  I’m often asked why I would choose MongoDB over SQL, and here are the reasons I usually give…  

Freedom

Unlike traditional relational databases, MongoDB is schemaless, which means you can have two completely different documents (rows) in the same collection (table).  For example, both of these are valid documents and could be rows in the same table:

{ name: ‘Matt’, likes: ‘Mongo’} {company: ‘Agio’, location:[‘Norman’, ‘New York’, ‘Raleigh’]}

Using different fields in this way obviously isn’t a recommended best practice for data retrieval and administration, but it’s entirely possible if needed.

From a development standpoint, MongoDB is ideal because you don’t have to figure out joins when querying documents – joins don’t exist in MongoDB.  Instead, collections should be planned to use subdocuments when a join would normally have been necessary.  In one of the examples above, {company: ‘Agio’, location:[‘Norman’, ‘New York’, ‘Raleigh’]} , a join would have been necessary in SQL to find that data, but in MongoDB, a simple find query would return the document.  

Scalability

This is my personal favorite feature of MongoDB.  You’re not required to have a huge expensive server to run it; whereas with traditional RDBMS, when you need more power or data processing speed, you have to upgrade your server.  This gets expensive quickly and there’s an upper limit you can hit.  With MongoDB, you can just add another inexpensive computer to your replicaset and get the same increase in power.  It’s called “scaling out,” and it can be inexpensive in comparison to “scaling up.”  When you’re taking advantage of MongoDB’s replica set and sharding features, you scale out and have built-in redundancy at a fraction of the cost of a traditional server.  

Ease of Administration

I’m a huge fan of how easy MongoDB is from an administration standpoint.  MongoDB logs are straightforward and describe any issues exactly.  There are built-in tools for finding long-running queries, replication lag, and replication issues.  In addition, it’s incredibly simple to create a config file and get a new replicaset spun up or to add to an existing replicaset.  If you ever forget a process or command, the good folks at Mongo have an extensive set of documentation readily available online.

I’ll not be so bold to say that MongoDB is 100% the future of databases, but it certainly could be.  Every new release of the DB engine adds new features and makes the system more robust. I look forward to seeing what the next 10 years brings for the little DB engine that could.

Learn More