I have mainly worked on RDBMS databases. Recently studied MongoDB and liked where we don't have to define schemas upfront. So application developers straightaway can start writing the code. Major drawback that is stated in most of the articles is that MongoDB(or any other document based DB) is not good for transactional requirement. I am wondering why its not good for transactions. Just trying to understand with the help of use case we have in any web application

Consider a use case where we have user profile page with multiple addresses like primary, secondary and mailing address.User can have multiple bank accounts. In RDBMS we will create below tables

  1. User(Table user_profile)
  2. Address(foreign key pointing to user table)

User and address are created in one transaction but both address and user creation should be atomic.

  1. Account (foreign key pointing to user table)

With MongoDb there will be single User JSON document containing array of address and array of accounts. So my understnading is there is no need of transactions in mongodb at the very first place in many places because it will store all user related stuff in single document . But yes in some cases where transaction is happening across users then we will be needing transaction like account transfer from one account to another account.

So the way documents are stored in MongoDB, most of the places where transactions are needed will be eliminated. Is n't it ? If yes is there a way where we can maintain transaction across documents also probably through two phase commit ?

I see a good reason to use mongodb or any other document based DB even for applications which requires transactions in RDBMS but MongoDB eliminates the need of transaction itself except where transaction is required across document. Using document based DB will provide the advantage of faster development, better fetch and update calls.

Let me know if understanding is correct ?

Update :-

Other plus of Mongo I see are :-

  1. Joins are not required so better performance and less complex queries.

  2. Read/write throughput is better in mongo(I haven't tried it myself just stating from advocates of document stores)

  3. If for particular document I need to store some extra information(say I want to store comment field for specific types of document) I don't have to add column for all documents,

  4. It stores the data in json form

  5. Eliminates the need for transactions in most of the places like the example I stated above because it stores all connected information in single document itself


The biggest and only con I see is not able to support transaction across documents which most of the web applications are required at some point of time though numbers can be few. We need to resort to techniques like two phase commit in those cases.

Also I agree the statement So application developers straightaway can start writing the code can be boon or bane depending on situation. In RDBMS , its kind of we make the policy , review it upfront and then every one follow it. If we want to change that policy, its bit difficult. In Mongo like DB, you don't have policy in place, but you have to decide some informal contract and rely that every one follow it. Obviously there are chances here that it can be misused , so it(application code) has to be reviewed more often to confirm the contract we decided upon and if for some reason we want to change contract its much easy to incorporate here

  • 4
    "So application developers straightaway can start writing the code." Unless they are writing a prototype, this usually means "devs can straightaway start writing buggy, conceptually flawed code that will not work for a variety of reasons they could have found out if they had thought about it up front."
    – Andres F.
    Mar 8, 2017 at 14:49
  • 3
    Your update is puzzling. "Joins are not required"? So what? Joins are not required in relational databases either. "It stores data in json form"? First, why is this a plus? Second, you can do this with relational DBs as well. "Eliminates the need for transactions"? It does so at the cost of other problems, like needing to have every connected information in "a single document itself". I suggest you really try to understand why -- if at all -- you need MongoDB or any NoSQL database at all. It seems to me you haven't provided good reasons.
    – Andres F.
    Mar 9, 2017 at 1:33
  • I did not get you from Joins are not required in relational databases either. Consider I have user name and I want to find his address. I need joins. ` 2. It stores data in json form? Now in ajax world most of communication happens in json. Now , I see it consistent across the layers where developers does not have to struggle with different data representations 3. Eliminates the need for transactions ? well everything in world has cost. What I meant was it depends upon the scenario but just saying mongo does not support the transaction is not minus Mar 9, 2017 at 1:53
  • 2
    1- You absolutely do not need joins to solve the user-address problem if you store users in the same row as their address(es), which is what you'd be doing with Mongo anyway. 2- Json as an exchange format has nothing to do with storage, 3- It's definitely a minus that Mongo doesn't support transactions. Again, I think you do not understand the trade-offs involved and have serious conceptual problems, including but not limited to databases and data modeling.
    – Andres F.
    Mar 9, 2017 at 3:01
  • Nitpick: "4.It stores the data in json form". MongoDB doesn't store JSON. It stores BSON. The MongoDB shell just presents it as JSON to the user. But the distinction can be important in some situations.
    – Philipp
    Mar 9, 2017 at 15:01

3 Answers 3


Yes, your understanding is correct.

If you perform multiple changes to the same document in a single operation, that will be an atomic process. But when an operation affects multiple documents, there is no guarantee that any queries in between won't return partially documents before the operation and partially documents after the operation.

MongoDB's nested documents encourage to put data in a single document which would be distributed over multiple rows of multiple tables in a relational database. That means such operations are not as common as they are in relational databases. But if they occur and consistency is important, you can handle them with a two-phase commit. This is a really ugly workaround, but can work if you have no other way.


Your only(main - post edit) plus for mongo seems to be "So application developers straightaway can start writing the code"

But this must be caused by your current development practices rather than the technology. I can create those tables in mssql just as quickly as in mongoDb.

I assume that in your RDBMS work you have to push that work off to a DBA team and wait for them to do it?

The trouble is that, not having an enforced schema doesn't free you of the job of designing how you are going to store your data. Indeed it may even complicate it if you make changes later and then have to worry about v1 and v2 addresses for example.

  • please see my updates for other pros of MongoDB I can think of Mar 9, 2017 at 1:23
  • @user3222249 I'm afraid your update still doesn't introduce good reasons for using MongoDB. Ewan's answer still applies.
    – Andres F.
    Mar 9, 2017 at 1:34
  • 2
    sorry @user3222249 its clear from you edit that you dont really understand the difference between the relational and no-sql databases. The pro of mongo over sql is in its ability to scale, but it comes with massive downsides from the point of view of a relational db
    – Ewan
    Mar 9, 2017 at 7:33
  • @Ewan would appreciate if you can elaborate what makes you to think that I don't understand the difference b/w relational and no-sql databases. Would be really helpful for me to correct. For your statement The pro of mongo over sql is in its ability to scale, but it comes with massive downsides from the point of view of a relational db I understand we can scale mongo easily with the help of sharding but my point is that kind of scaling is required few applications. Mar 10, 2017 at 4:44
  • With my post I am just trying to understand what's that massive downside even if I use mongo for application which does not require that much scale and does not require transactions across document ? Mar 10, 2017 at 4:59

In RDBMS , its kind of we make the policy , review it upfront and then every one follow it. If we want to change that policy, its bit difficult. In Mongo like DB, you don't have policy in place, but you have to decide some informal contract and rely that every one follow it.

I think this view of the difference misrepresents what DBMSs actually do. An DBMS isn't simply a dumb provider of (unfortunately necessary) storage services to front-end programmers, which can be evaluated according to how much it gets in the way of their way of doing things.

For one thing, database systems can also implement business rules; and if a business rule relies on traversing a lot of data, the RDBMS is a good place for it to be implemented.

A realised database design in a RDBMS also acts as an explicit statement of commitment to a particular data model. An informal "contract" can never have the same universal power of enforcement.

I get the feeling that much of the hype around alternatives to RDBMSs (aside from the scalability question, where advantages seem to be genuine) arises from discomfort with this idea of following enforced rules about how data is stored. But that discomfort, and the (in my view) misguided attempts to be liberated from it, misses some very important points:

  1. RDBMSs are a very mature engineering technique. While the structure of a database may appear to be static and unchangeable, a well-designed normalised database actually already has facility for the model to be changed (or for data to be migrated) built-in, through its adherence to normalisation rules.
  2. Related to this: proponents of other database types seem often to vastly over-estimate the difficulty of setting up or changing an RDBMS database model. It really is not as difficult as it's presented. The difficulties which are inherent in it are inherent to any storage system which has to deal with both new and legacy data: there's no NoSQL escape-route here.
  3. The constraints imposed by a particular RDB design are not necessarily arbitrary and cumbersome. A database design can be the way it is because of real business requirements. Or because it provides the most efficient way to store, process and summarise large quantities of data.

None of this should be taken as meaning that MongoDB isn't an excellent solution for certain purposes. I just think that it's often hyped as the one best solution, without a clear understanding of what those purposes are, and with a highly-distorted view of the utility of RDBMSs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.