The Verdict On MongoDB, From Devs And Ops

MongoDB, the leading NoSQL database, incites a lot of passion on the web. There are some who love this schemaless database and others who think it’s overrun with challenges. We polled several of our Rackspace developers and operations engineers to find out what they think of MongoDB.

What Fans of MongoDB Like…

Many developers are won over by MongoDB because it’s schemaless. This gives developers both freedom and flexibility to rapidly create an app. “From a development standpoint, MongoDB is zero friction,” says Phil Toland, a Rackspace developer manager. Users are able to take raw data and insert it into a database with a JSON format without worrying about placing a structure around it.

The Document Model
The document model is very appealing to many application developers. The MongoDB drivers do a great job of serializing data to native structures that are not only familiar to developers, but also very powerful. “The document model fits nicely with how developers work today—especially if they want to display data back to the user,” says Chris Lalonde, co-founder of ObjectRocket. “MongoDB made great decisions early on by creating BSON.”  BSON (bin­ary-en­coded seri­al­iz­a­tion of JSON-like doc­u­ments) is both the wire format and on-disk format for MongoDB, which enables MongoDB developers to read and write documents to the database. 

Adopting a BASE Design
Many of today’s developers have gravitated to MongoDB because of its BASE (Basically Available, Soft state, Eventual consistency) properties as opposed to the ACID (Atomicity, Consistency, Isolation, Durability) properties of traditional relational databases. Modern web applications that have to scale for millions of transactions must opt for a more relaxed database consistency in favor of availability.

Built-In Scaling
MongoDB has built-in sharding (horizontal scaling), which can maximize the scalability of your database. Spreading data across multiple machines ensures adequate storage capacity as your data grows. It can also help optimize the ratio of compute resources to data. “MongoDB, Inc. thought about scalability and incorporated that into the design of MongoDB from the onset,” says Kenny Gorman, co-founder of ObjectRocket.

Less Complexity
MongoDB’s schemaless structure also enables developers to rapidly modify the app as business needs change. With relational databases, any new or modified feature request can result in a change to the database schema along with a migration. The schemaless nature of MongoDB removes the complexity as stakeholders make changes. “MongoDB allows us to be flexible with changing requirements, without having to do a database migration when things change,” says Rackspace developer Brady Vitrano. This can save many hours of migration time when the business decides to add a column to a huge datastore.

The MongoDB Gotchas…

New Kid on the Block
For all the reasons to love MongoDB, there are still some aspects of the datastore that rub people the wrong way. One thing is that the platform is not as mature as other more established datastore systems. “MongoDB hasn’t been around as long and is consequently a newer, less tried and true technology,” says Rackspace Chief Security Architect Major Hayden. “Some people might not have the knowledge to administer, tune or get the best performance out of it.”

The Shard Key is Critical
While the promise of built-in scaling is enticing, there’s pressure to choose the correct shard key from the very beginning. The shard key is the “indexed field or an indexed compound field that exists in every document in the collection” as defined by MongoDB, Inc. Making a poor decision on what value the shard key could take can dramatically decrease the performance of your application. “Selecting an optimal shard key can be tricky, and in many cases is a compromise of many tradeoffs,” says Gorman. “This choice is critical when deciding on how to scale MongoDB.”

MongoDB’s concurrency model is drastically different in design than traditional datastores. MongoDB relies on a model of yielding versus strict locking of structures, sometimes called a readers-writer lock. Initially, the lock scope of MongoDB was database wide, but later versions have a scope per database. Still, this is a fairly wide lock scope so developers and admins need to be aware of this. Each shard in a sharded cluster has its own scope so sharding can extend the number of scopes any given workload sees. Still, understanding how a given data model will perform in terms of locking as well as the administrative commands that exasperate locking continues to be tricky.

Schemaless Requires New Discipline
“Schemaless can be daunting without some order,” says Gorman. As developers enjoy the agility of MongoDB, they also need to have systems in place to ensure there aren’t conflicting data elements that could cause corruption. Some drivers have Object Mappers that help alleviate some of the potential problems, and some teams have implemented a schema at various levels of the software stack. This helps them keep track of everything as the application evolves. Remember, the underlying application may still use schemas of some sort even though the data store doesn’t.

If you want all the advantages of MongoDB without having to worry about any of the headaches, check out ObjectRocket by Rackspace. ObjectRocket has fine-tuned hardware to get the highest performance out of MongoDB.

  • Was this article helpful ?
  • Yes   No
Garrett Heath works on the Rackspace Social Marketing team. His previous experience includes work as a technical project manager in the cloud and as a content marketer. He enjoys writing about how the cloud is spurring innovation for startups, small businesses and enterprises. You can also read his work at CMO Digital Forum. In his free time, Garrett writes about food and local San Antonio culture at SA Flavor.


    • I think the verdict is, as with almost all things development related : your results may vary, choose the right tool for your particular job.

  1. I’m not sure why I’d use MongoDB when Postres’s JSON type offers a viable option for storing schemaless data. I found when using Mongo, I just had to do too much work that I felt the database should have done for me. Not having joins is a real pain; even on projects that should fit pretty solidly into the Mongo realm, things always got complicated. I keep going back to SQL. And most of us don’t need “web scale”.

  2. Yeah, um … there’s no “verdict” here. The content isn’t bad, but the headline so misleading it diminishes authors work and value of article.