Mongoid vs MongoMapper: Two Great MongoDB Libraries for Ruby
It's been almost a year since Ric Roberts posted about using MongoDB and MongoMapper and I've seen an explosion in the number of people using these tools in the Ruby community since then (I use them heavily on coder.io too).
MongoMapper has become the de facto standard way to use MongoDB from Ruby, but it's not the only game in town. Mongoid, by Durran Jordan, has recently been creeping up in popularity too, and with a stunning project site and robust documentation, it deserves some attention.
At first glance, Mongoid and MongoMapper seem to take similar approaches and have very similar APIs, so I got in touch with both Durran Jordan (Mongoid) and John Nunemaker (MongoMapper) to split some hairs and it turns out they have different motivations, aims, and, underneath it all, they target different use cases pretty well.
If you're reading this far, you're probably already using MongoDB or have some ideas on how you'd want to use it, so I'll skip the pleasantries and get straight to the developers' insights into why you might prefer their library over the other (or even why the other library is better). First up, Durran Jordan of Mongoid:
- Mongoid is completely Rails 3 compatible, and uses ActiveModel all
over the place (validations, serialization, etc), where MongoMapper is still focused on Rails 2 and uses the validatable gem for its validations.
- Mongoid officially supports and works on Ruby 1.8.7, 1.9.1, and 1.9.2 head.
- Mongoid supports embedded documents more robustly, performing the MongoDB atomic operations on any area of the hierarchy internally. ($set, $push, $pull, etc). With MM you need to explicitly tell it to do these operations.
- MongoMapper has better relational association support and works like this as default.
- MongoMapper is more extensible, with a plugin architecture that makes it pretty easy for people to extend it with their own libraries. Mongoid does not have this.
- MM supports identity maps, Mongoid does not.
- MM has a larger community, and probably more 3rd party library support. I went crazy on documentation and rdoc.
- Mongoid supports Master/Slave replication clusters. (Writes to master, round robin reads to slaves) MM does not.
- Mongoid has an extremely rich ARel style criteria API, MM use AR2 style finders. (Ed: This may not be such a big issue in MM's case since version 0.8 added a new query DSL.)
The biggest comment I have gotten from people, and why I designed Mongoid the way I did is predictability. For one, wrapping the driver cursor when dealing with huge documents and lots of them (in the millions) needs to have predictable performance and memory consumption. We noticed MM didn't deal with large documents (over 500k in size) very well as far as these characteristics go, but handles small documents better than Mongoid. (This may have changed over the past few months, but was an issue for us and others I have talked to.)
Durran Jordan (Mongoid)
I also asked John Nunemaker to give some reasons why someone should or might prefer to use MongoMapper:
- It's built from the ground up to be very extendable and gets more so with each release. Sweet plugin system makes this possible and powers every feature (check out
- Very familiar for those coming from ActiveRecord (querying, scopes, saving, validations, callbacks, etc.) while still allowing you to take full advantage of the things that make MongoDB awesome.
- I bet the farm on MongoDB with Harmony (which will hopefully someday pay my bills) so MongoMapper is not going anywhere. It will continue to get leaner, meaner, and easier to use. Big plans my friends, big plans.
John Nunemaker (MongoMapper)
I'm likely to stick with MongoMapper myself, mostly because I know John, appreciate his dedication to MM and I'm already using MM in production, but Mongoid is an attractive option, especially for Rails developers or newcomers who might prefer its slicker presentation and "getting started" documentation.