Reasons for and against moving from SQL server to MongoDB [closed]

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.)

cons

1. (the lack of / different vision on) durability (read http://www.mikealrogers.com/2010/07/mongodb-performance-durability)
2. No transactions
3. No constraints
4. Aggregation with MapReduce is slow and you need to write code for something like group-by
5. Reporting is harder, the developer defines the relations but business analysts can't build their own queries, they can't for example do a 'minus' ('except' in sql server lingo)

pros

1. you can easily add new 'columns' and 'tables'
2. speed
3. sharding (still beta)
4. document matches more closely to an object than a set of relational tables so mapping becomes easier
5. It broadens the mind

Your mileage may vary, but this is a quick graph I put together to compare the speed of updating multiple "table rows" (non-hierarchical flat document in MongoDB) with and without an index to give us an idea of how it would scale for our application.

I've been poking around with it a few days now. This is what I can say about it:

FOR:

• No more SQL statements
• Your database resembles your classes not the other way around
• Your "schema" is more flexible
• Scales well
• Very easy to get started with
• < opinion>It's cool< / opinion>

AGAINST:

• I'm currently trying to implement a custom Membership Provider And Role Provider for my mongo app but somehow my MemberShip user class has NULL fields when I try to retrieve it from mongo.
• Somewhere I've read about the C# driver that it's relatively young but stabilizing so expect some changes. (Although this wouldn't hold me back)

One thing i noticed that's missing from the tutorials: Initialise your lists inside your object otherwise it will throw an error while trying to .save(yourobj). The safest thing to do is write a constructor in your class that makes sure you don't have any NULL objects inside your object. This way you won't get an error if you forget something.