In my current project, we’re using a no-SQL database called MongoDB. It’s superfast, document-based, and it’s exactly what we need. It also scales well, but it has at least two things people have to know about before the leap of faith:
1) it has so-called eventual consistency (explained some other time),
2) and there’re no atomic transactions.
One might say, what do I want with the DB that has no atomic transactions? Well, things are a little different with MongoDb.
There’re no atomic updates that would span many documents. But the operations for one document, they are atomic.
Why it means so much is because recommended design approach with MongoDb is that the document is a self-contained entity, with little or none external dependencies. It can contain nested objects, lists of nested objects, etc. So for example, an order can contain all the items in it. Or the article can have a collection of related documents inside.
This, of course, means that we’re having some de-normalization. But wholly normalized entities are a no-no for MongoDb, because it has no joins and therefore, all such operations require additional DB calls.
So, there’s no transactions, but the document itself can contain whatever would be spanned by a transaction, and the document operation is atomic. Is it good enough? This question should be answered specifically for each data domain and each system.