TrustRadius
MongoDB -- the "Honey Badger" of NoSQL
https://www.trustradius.com/nosql-databasesMongoDBUnspecified8.2290101
Jon Kern profile photo
January 12, 2018

MongoDB -- the "Honey Badger" of NoSQL

Score 10 out of 101
Vetted Review
Verified User
Review Source

Overall Satisfaction with MongoDB

We are using MongoDB as the backbone of our latest product offering, the Project Portal (v0.9 released Jan 2016). This is a Saas offering that we essentially white-label to our OEM clients for their customers and end users. MongoDB offers a robust, scalable, simple-to-get-started solution for the persistence layer of our Rails app.
  • As a software architect, I like the ease with which MongoDB avoids the typical "impedance mismatch" between traditional SQL and the object-oriented problem domain classes. MongoDB (via mongoid) in our Rails app is like a "hot knife through butter." It is much more akin to an OODBMS than anything else.
  • MongoDB is easy to use throughout product development as it is the "honey badger" of databases. As your product rapidly goes from idea to startup to scaling, MongoDB makes it easier than any SQL database I ever used. You spend more time building your solution, and less time worrying about feeding, nurturing, and migrating the SQL beast.
  • The ease with which you can spin up replica sets is amazing. No more excuses that you could not build a robust persistence layer. (Especially if you tack on services like MongoDB cloud offerings.)
  • I also take advantage of the geo-aware spatial indexing. To be able to geocode users, logins, problem domain classes (entities with an address), and do geo-aware queries -- like find me all of the X within Y miles of point Z. Booyah!
  • I love the idea of Map-Reduce native support in MongoDB. Admittedly I have not used it as much as I would like -- it always seems to trip me up.
  • Recent additions to the aggregation queries have helped reduce (no pun intended) my need to better wield the weapon that is Map-Reduce.
For my time and money, I would start off almost every project using MongoDB -- even if I knew it might not be the ultimate final DBMS.

Why? Because, in the early stages of product development, I am rapidly iterating on the domain, and other parts of the app. Sometimes changing my mind on major pieces of the architecture as we prototype early solutions.

MongoDB works as freely and as quickly as I do. SQL databases do not. They get in the way, slow me down, tick me off.

However, not all apps are well-suited for NOSQL. So if there are performance needs or other reasons that may point to SQL, then at some point I migrate.

Controversial, I can imagine. But I could explain it over a beer. Or three.
  • Due to MongoDB's honey badger approach to persistence, it allows our teams to run fast at implementing our web apps.
  • MongoDB is easy to administer -- especially because we use MongoDB Cloud to backup and monitoring.
  • Admittedly we are not storing gazillions of documents (only 15GB), and we are not "pushing the envelope" on performance, so we do not require any database admins.
I only briefly looked at CouchDB after I already began using MongoDB. Naturally, I have used many relational SQL databases.

Since MongoDB did everything I needed, I saw no need to look around for alternatives.

(Okay, full disclosure. I am an "association" vs "inheritance" object-oriented snob. In Rails, ActiveRecord implements persistence via inheritance for SQL databases. The MongoDB gems like mongoid and mongomapper add persistance via association. Boom!)
I am looking forward to increasing our SaaS subscriptions such that I get to experience global replica sets, working in reads from secondaries, and what not. Can't wait to be able to exploit some of the power that the "Big Boys" use MongoDB for.
For most every basic web app that I have developed, MongoDB is well suited. I find it hard to imagine scenarios where it would not be...For apps where we have dynamic, user-controlled attributes, MongoDB makes this really easy. I would imagine MongoDB might be least appropriate for teams not interested in trying to learn a NoSQL approach. Try a skunkworks project then...