Monday, November 16, 2015

2015 with MongoDB: A Summary

Hello readers! Sorry for the ridiculously long time I took to write a new post after my old one. Since I was dormant for most of 2015 save the earliest weeks, I thought it would be a good idea to summarize a bit of what I used, learnt or even just googled at work since the start of the year. I hope to do one of these every week until the end of the year if possible.

I want to start with MongoDB, ubiquitous as it is.


  • Used in production when hosted by MongoLab.
  • Expected a lot of things to go wrong given how ugly its reputation is but surprisingly, was really stable.


  • Really fast setup time. Download, extract and run was the motto here. No messing around with creating tables first and setting up the schema or anything.
  • Data model is easy to grasp - bunch of tables on which you do simple lookups by a bunch of different keys including the primary. Good secondary index support.
  • Geo spatial indexes - very few have these out of box. Easy to do a lookup for a point which is atleast or atmost a distance from another point (think dating sites).
  • Regex text search - I love regular expressions and it worked wonders for me.
  • Note that the combination of the above two isn't found on a lot of datastores that can distribute and shard themselves. This and the secondary indexes (and all other positives) make it attractive to quickly prototype an app backend.
  • Widely available thanks to SaaS companies like MongoLab and Compose. The former gives you a free 500mb instance for bootstrapping your development phase.
  • Great Go and Node.js drivers
  • Available in ArchLinux repositories


  • Huge startup time when first started due to allocating loads and loads of space for storing nothing.
  • Atomicity is within a 16-mb file (while Cassandra partitions go a few gigs). Not enough for my data modelling needs.
  • Lack of server-side 2-phase commit support - I don't need strongly consistent data but appreciate a simple mechanism to rollback updates if an operation only partially completed.
  • Together the above two dislikes made data modelling hard for specific use-cases I had.
  • B-Tree everywhere means at minimum an operation is O(log(n)). I never grew big enough to notice it, but the theorist in me cringed.
  • Its presence in the "MEAN" stack which brings a whole lot of clueless noobs onboard giving MongoDB a bad name. Just trolling lol.


  • MongoDB 3.2 looks very promising and it is always good to see a project evolve like this!
  • WiredTiger engine expected to become default in version 3.2 on most SaaS platforms. Same API as 3.0 but better performance equals migration win for existing customers.
  • The most popular reason why people hate MongoDB, the way it handles locks shouldn't be an issue in 3.2+ versions: see
  • Personally, I believe in using whatever suits the job and the next time I see a MongoDB-friendly project, I'll be happy to give it a spin again - but probably with a newer storage backend.

That's it for today. Another quick tech summary coming soon.

No comments:

Post a Comment