State of MongoDB March, 2010

Every once in a while, I think its important for us (the core MongoDB team) to give a broad picture of where we think MongoDB is and where we’re hoping to take it.  This is useful both as a gut check for us, to give the community some insight into what we’re thinking, and to make sure we’re all on the same page.

MongoDB has made great strides in the last year.  The first public release was just over a year ago (2/11/2009) and since then we’ve seen tremendous support and interest from the developer community.  We’ve made a lot of great progress on the core database, drivers and tools.  The community has contributed a large and growing number of great drivers and tools, as well as invaluable testing and feedback.  We’ve also seen a really great amount of production MongoDB installations coming online in the last year.

MongoDB got 2 stable releases (1.0 and 1.2) and there is a third coming (1.4) which has many things we’re very proud of:  better concurrency, geospatial indexing, “usability” enhancements and speed enhancements to name a few.  We’re planning on a stable release every 3 months as a way to balance speed, carefulness, and practicality.

So, where are we in our grand view of the world: about half done.  MongoDB is in a great place today, but we have a long way to go.  MongoDB was never designed nor intended to be a niche database for a small subset of problems, but a new type of database, that solves lots of real world problems for a large subset of the developer community.  We’re getting there, and we’re suitable for a lot of problems, but there are lots of things we still need to do.  So if you’re looking at MongoDB and saying “its not good enough for this” or “it would be great if only it had X,” its very likely we agree with you.

Some major things we’re thinking about for the next 6-12 months

• better replication: real time, replica sets, more options for data durability
• production ready sharding
• more features for working with embedded documents
• flushing out more atomic update operators
• single server durability
• full text search

Talking about embedded objects as one example, we added support for this very early on because we think its often a better way to model your data in the database.  Being able to store addresses for a user, or tags for a blog post inside of the main document is great for many reasons, particularly speed and manageability.  This is a very different paradigm than relational, and we’ve had to add a lot of features to make it work nicely: indexed embedded fields, in-place incremental updates,  etc…  We still have many features we want to add that people have asked for to make it even nicer to program with embedded documents.

I’ve recently changed the way I describe MongoDB when I first talk to people that I think sheds some light on how we’re thinking.  MongoDB wasn’t designed in a lab.  We built MongoDB from our own experiences building large scale, high availability, robust systems.  We didn’t start from scratch, we really tried to figure out what was broken, and tackle that.  So the way I think about MongoDB is that if you take MySql, and change the data model from relational to document based, you get a lot of great features: embedded docs for speed, manageability, agile development with schema-less databases, easier horizontal scalability because joins aren’t as important.  There are lots of things that work great in relational databases: indexes, dynamic queries and updates to name a few, and we haven’t changed much there.  For example, the way you design your indexes in MongoDB should be exactly the way you do it in MySql or Oracle, you just have the option of indexing an embedded field.

So in conclusion, I hope you find MongoDB useful and productive now, we hope to make great strides in the next year, and are grateful for the community’s support, advice, debugging and interest.

-Eliot and the core MongoDB Team