Using a NoSQL database over MySQL

I think that it very much depends on what you want to store in the database. I don't have experience with CouchDB or Cassandra so I will let someone else speak for them but I frequently use MongoDB and MySQL.

If you were developing application that required transactions e.g. a billing application you would definitely want to use MySQL because of its support for transactions. MySQL is ACIDic that is it is Atomic, Consistent, Isolated and Durable. What that essentially means is that when you update a row in MySQL - it is GUARANTEED to have happened. However the issue with MySQL is that it does not scale horizontally (by adding more and more servers) very easily. MySQL servers tend to be scaled vertically by adding more memory, HDD space etc but they eventually hit a ceiling and it can reach an enormous cost.

MongoDB is a document database. It stores JSON-like documents inside collections and is schema-less - so each document can be different. This is great for flexibility in your application. A lot of developers say that noSql solutions are developed more for programmers and they tend to be much easier to build with (in my experience). In addition MongoDB scales horizontally by sharding the database into chunks. In fact this can even be automated now.

But there are drawbacks to using MongoDB. If you are using it in production you really MUST put in a replication slave with it. This is because MongoDB does not have full single server durability. So if you suffer a power failure you will probably have to repair the entire MongoDB database which can take hours. This is probably not a big deal cost-wise if you are well-funded but if you are a new organisation with little money it can be difficult (use cloud computing? ). In addition MongoDB does not support transactions which is necessary to guarantee Atomicity and Isolation. Finally MongoDB is only eventually consistent (though I have seen a few sides to this argument) - which means that when a

I've found that NoSQL databases are poor for prototyping, because you have to structure your data with the knowledge of how you'll get it out. With NoSQL the schema matches the needs of your queries. But in a prototype you don't yet know how you'll get the data out, and you'll find yourself either doing way too many queries or refactoring your schema every time you want to add a new feature to your prototype.

With a relational database, you just normalize your data and you can ask any question you want. You only need to refactor the schema if your model didn't match the real-world entities properly.

I've had to refactor my MongoDB database several times, once each time I added a new way to look at the data in the web app. Not surprisingly, I'm converging on a relational schema that takes little advantage of the nested arrays and objects possible with a document database.

If you look around you'll see that the most successful uses of NoSQL are for people who developed their app with a relational database, and now that they understand their features, can switch to NoSQL knowing exactly what to put into it to satisfy their queries. If you're still exploring your app and the kinds of questions you'll want to ask of your database, I recommend sticking to relational.