Why use NoSQL instead of mySQL?

I’ve been watching/reading all the hub-bub about NoSQL databases.  This is the part of the blog post where I briefly recap the NoSQL movement: schema-less, key/value stores, document stores, yadda yadda yadda. But you have Google too.  (Although this one is my current favorite).

I’ve got a couple applications brewing, both for work and personally.  So how do I evaluate NoSQL vs MySQL?  When should I use NoSQL instead of MySQL?  When should I use NoSQL instead of any RDBMS, for that matter?

After reading about NoSQL, downloading a couple, trying a few tutorial, this is what I’ve come away with:

  • It seems to me the primary advantages of NoSQL over MySQL or another RDBMS are speed and scalability.  From everything I’ve read, NoSQLs tend to be hella-fast for a variety of reasons.  Depending on the particular system, it is fast because: the entire DB is stored in RAM, or you do fewer JOINS due to a document store, or an extremely efficient B-tree data structure, or Map/Reduce, or others.
  • The big bonus for MySQL is, of course, ACID compliance.  The database helps ensure that you save the only data you wanted, when you wanted to save, and that it’ll be in a good state when you need it.  If you have something like a bank, you want that kind of data integrity.  If you’re serving millions of status messages, you may not care as much that everything is exactly right, or that everything is consistent at every instant across your data cluster.
  • I think an equally important (though I haven’t read about it very much) is that NoSQLs may be a simpler, more natural way to conceptually model the data in your application.  In document stores like CouchDB or MongoDB, I just add new fields to a document.  Just like I was writing extra information on a piece of paper — I don’t have to update every other piece of paper in my filing cabinet.   It may make sense to think of you data as a document, rather than scattered across various relational tables.

As I’ve said a couple times in this blogit’s all about picking the right tool for the job.  When I am designing a web site for a client, I have a number of tools I can pick for wireframing and prototyping.  When I’m coding a site, I have a number of web frameworks, programming languages, and coding guidelines I can choose from.  In the same way, NoSQL gives people another choice for persisting data — one that is 1) easier to get your head around than relational databases, 2) addresses some scaling and speed issues that rear themselves at high volumes, and 3) is relatively cheap or free to use.

If I’ve missed something major about the relative merits, I’d love to know about it.

I’m choosing to use MongoDB in some of my personal projects because I want to add a new technology tool to my toolset.  But for work, given our current usage and application needs, I can’t imagine seriously trying to roll NoSQL into a production system in the near future.  I’m not saying our IT Ops would laugh at us, but there’d be a fairly high burden of proof.  In terms of modelling data in our applications, I can’t think of something that in NoSQL that I couldn’t do in an RDBMS.  Again, I’d love to know where I’m wrong in this. One day, our loads or speed requirements may force me to revisit this assumption.