The idea is that you won't need database-wide transactions if your data is structured into "natural aggregates" such as orders, articles, profiles, etc. In a r

The idea is that you won't need database-wide transactions if your data is structured into "natural aggregates" such as orders, articles, profiles, etc. In a relational database, something as simple as an "order" has components in lots of different tables -- customer, product, order, line_item, shipping_method, etc -- so you have to lock all of those tables when doing an INSERT or UPDATE. In the ideal MongoDB implementation, an "order" would be a document of its own, and all the other parts would be attributes or nested structures. So you only really need a transaction for the document itself. Other documents could be inserted/updated at the same time without creating a conflict. That's the theory, at least. Martin Fowler has a good Youtube on "Introduction to NoSQL" that I sometimes show to my students: https://youtu.be/qI_g07C_Q5I https://youtu.be/qI_g07C_Q5I The other thing about NoSQL is that it's often used for write-once, then read-only applications. Twitter, Facebook, or Instagram would be good examples. When 1% of your queries are INSERTs and 99% are SELECTS (with UPDATE and DELETE almost never occurring), you really don't run as much risk of anomalies. I would not recommend NoSQL for something like a banking application where you're doing lots of updates and need to guarantee consistency.