Question

I know this is a big question and it’s not a yes or no answer but we develop web apps and are looking into using MongoDB for our persistence solution. Combining MongoDB with NoRM for object storage.

What I want to ask is what pitfalls have you experienced with switching from SQL to mongo? When is mongo simply not the right solution and is mongodb’s advantages enough to move development from SQL?

Answer 1

In my opinion the format of your data should be the primary concern when choosing a storage backend. Do you have data that is relational in nature? If so, can it and is it a good idea to model the data in documents? Data modeling is as important in a document database as in an relational database, it just done differently. How many types of objects do you have and how are they related? Can DBrefs in Mongodb do the trick or will you miss foreign keys so much it will be painful? What are your access patterns for the data? Are you just fetching data of one type filtered by a field value, or do you have intricate fetching modes?

Do you need ACID transactional integrity? Does the domain enforce a lot of constraints on the data? Do you need the scalability factor of a document database or is that just a “cool” thing to have?

What are your consistency and data integrity requirements? Some NoSQL solutions and MongoDB in particular are quite loose on the write consistency in order to get performance. NoSQL is no uniform landscape and other products, e.g. CouchDB has other characteristics in this department. Some are tunable too.

These are all questions that should go into the choice of storage.

Some Experiences

• Doing extensive reporting on the stored data can be harder when using MongoDB or any document database and some use cases have been combining RDBMS and document-db for that purpose.
• (Very) Different query model. MongoDB differs from other document-dbs too.
• Flexible to change data format/schema during development
• Unknown territory
• varying degree of maturity in drivers and frameworks
• Fast
• Simpler (in many ways) product and management tools (compared to many RDBMS products)
• No more impedance mismatch. The storage fits the data, not the other way around.
• Less friction and more direct access to data.
• Domain more tied to persistence (depending on the ORM “level” of NoRM, on how much it abstract away the backend. I haven’t used NoRM so I can’t answer that.)