Home > Cloud, Infrastructure > Is MongoDB a good alternative to RDBMs databases (like Oracle and Mysql)?

Is MongoDB a good alternative to RDBMs databases (like Oracle and Mysql)?

During the 10th Devoxx at Antwerp a presentation was given about MongoDB by Brendan McAdams from 10Gen.
This was one of the presentations during this event which I attended. I have to say I was pleasantly surprised by the ease of use and the features of this product. MongoDB is a NoSQL (non-relational, next-generation operational datastore and databases) database which is a schema-less database having huge advantages over most current existing RDBM databases.

The main pros of MongoDB can be divided in the following three:

  • Flexibility
  • Performance
  • Scalability

The aim of this article is to give an idea of this product, by giving an overview of advantages and disadvantages. Next, I will give some pointers to take into consideration in order to determine if this type of database is suitable for a specific situation or not. At the end of this article I will provide the link to the presentation that was given, providing more details (like example models & queries).


  • Schema-less
    This is ideal for flexible data model altering. It is easy to declare \ extend \ alter extra fields to the data model, and optional non used (nulled) fields take no space.
 Using RDBM databases one must run scripts first in order to update the model. In this case it can be done through coding and no scripting is needed.
  • Structure of a single object is clearer
    The structure of the model is in json and the structure is directly clear instead of deriving it from a table structure.
  • No sql or hibernate queries (complex joins).
    The nice thing about MongoDb is that the operations are easy to use (without any sql of course) and are key / value based.
 Easy expression language operators (i,e, $gt, $lt, ) can be used and usage of indexes & cursors is possible.
  • Tuning
    You can choose what level of consistency you want depending on the value of the data (e.g. faster performance = fire and forget inserts to MongoDB, slower performance = wait till
 insert has been replicated to multiple nodes before returning)
  • Ease of scale-out
    Scale reads by using replica sets. Scale writes by using sharding (auto balancing). Just fire up another machine and away you go. 
Adding more machines causes your working set to be distributed over all the machines.
  • Conversion \ mapping of application objects to database objects not needed.
  • Uses internal memory for storing the (windowed) working set, enabling faster access of data.


  • If something crashes while it’s updating ‘table-contents’ – you loose all you data.
    Repair takes a lot of time, but usually ends up in 50-90% data loss if you aren’t lucky. So only way to be fully secure is to have 2 replicas in different data centers.
  • Indexes take up a lot of RAM. They are B-tree indexes and if you have many, you can run out of system resources really fast.
  • Data size in MongoDB is typically higher due to e.g. each document has field names stored it
  • Less flexibility with more complex querying (e.g. no joins)
  • No support for transactions – certain atomic operations are supported, at a single document level
  • At the moment Map/Reduce (e.g. to do aggregations/data analysis) is OK, but not blisteringly fast. So if that’s required, something like Hadoop may need to be added into the mix

Well suited for the following situations

  • Scaling out
  • Caching
  • High volume traffic

Less suited for the following situations

  • High transactional  applications
  • Ad-hoc business intelligence
  • Problems which require a sql solution


Of course, using a NoSQL technology like MongoDB involves some trade-offs and a different mindset than the traditional RDBMS. The main advantages as mentioned before are flexibility, scalability and performance. As the noSQL principle looks promising it is not (yet) the holy grail and therefor currently cannot replace the RDBMs for each situation. It is a different type of database which can be a solution, based on the requirements of the situation. It will not replace RDBMs databases but it I reckon it might run well side-by-side in the future (delegating model / functionality at which MongoDB is good at).

To get more information on MongoDB please follow this link to see the presentation that was given this week: link to presentation

It contains more in depth information as well as some neat query examples and code examples.

  1. 20/12/2011 at 06:37

    Nobody ever claimed that noSQL databases are intended to replace RDBMS system. MongoDB is yet another tool in the toolbox of developers. Use the right tool for each project. Only programmers morons use one tool for all and everything (intentionally or just because they don’t know better).

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 275 other followers