Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Im a bit confused......the whole NoSQL and such. When would you choose to use something like MongoDB over something like Oracle or MYSQL? I dont really understand....the "difference" as far as usage goes between them.

From my Understanding NoSQL type databases aren't meant to replace RDMS......but what exactly are they meant to do?

share|improve this question
What have you been reading? Can you provide quotes or links or some background for us? We don't know how much you know -- or don't know. –  S.Lott Mar 3 '11 at 18:49
Until/unless they are moved here, there are several very similar questions on StackOverflow, including When to use MongoDB or other document oriented database systems? –  NickC Mar 3 '11 at 21:23

5 Answers 5

up vote 12 down vote accepted

I've used CouchDB before for three pets projects.

  • A micro blogging system.
  • For saving information for a little note taking app I made.
  • A general purpose brainstorming application.

The main reason why I chose this over something like MSSQL or MySQL is the flexibility you obtain when using it. No rigid schema. If three months down the line you need a certain table to have an extra field, and this and that, you just change it and it ripples out from there on out.

I used Beginning CouchDB by Apress to learn how to use it.

For example, CouchDB uses json to communicate to/from the database. If your language can POST data, then you can use it to communicate with the DB.

Also read: Why should I use document based database instead of relational database? on StackOverflow

share|improve this answer
Your first two examples sounds like a good domain for a traditional Relational DBMS. –  Jonas Jul 8 '11 at 10:57
@Jonas I don't agree. In the first example, even if the user details are fine tucked away in relational DB, we need the flexibility offered by doc DBs when it comes to the "social" part. connections, comments, tags etc etc. check this out: facebook.com/… –  yati sagade Sep 19 '11 at 14:01
@yati: That kind of application sounds similar to StackOverflow.com and I find it works very good with a traditional relational database. –  Jonas Sep 19 '11 at 14:08
@Jonas okay, but consider the complexity of changing the DB design during the operational phase in RDBMS. And, truly dynamic social sites require that new functionality be added time to time. And given the complex task of dealing with the message/chat system of FB, those guys have adopted Cassandra for that. While twitter seems to be reluctant, but they still have plans for something like Cassandra. In the link I gave in my previous comment, a lot of reasoning is presented on this topic. –  yati sagade Sep 19 '11 at 14:20
@yatisagade: I we are not talking about dynamic social sites. But a little note taking app and a micro blogging system. –  Jonas Sep 19 '11 at 14:56

To shamelessly steal from Renesis (actually I'm making this answer CW):

Using RDBMS's instead of other types:

share|improve this answer
+1 Thanks for the credit - no shame. –  NickC Mar 3 '11 at 21:21

When your data is not relational there can be major benefits to using NoSQL databases like performance and scalability (depending on the circumstances, of course). Some design patters like CQRS make it a lot easier to leverage non relational data in areas that would conventionally demand exclusive use of a SQL database.

It is common to use databases like mongo for cached data. For example, if you need to generate a report you could do a complicated SQL query that joins and aggregates a bunch of data on the fly, or you could just fetch a single json document from your mongo database that already has everything you need to generate the report. This makes reading data really easy (and fast!), but can make writing data quite complicated (this is where CQRS comes in).

share|improve this answer

The major win is when you want to shard data or have multi master databases. You can shard data in MySQL but it turns into a major pain. If you are doing a lot of writes it is often useful to shard the data across multiple servers, the problem is that if you want to have strong referential consistency while doing this it can be very hard if not impossible look up CAP theorem.

SQL databases have very good consistency but really bad partitioning support, NoSQL databases tend to go the other way. Easy to partition but often what is called eventual consistency. If you are building a messaging site that is ok, for a bank probably not OK.

The plus is that there are now multiple models to how to store data so there is choice in how you implement stuff, while before all you had were SQL databases.

SE Radio has had a few good episodes on this subject.

share|improve this answer
It has to be remembered that sharding is heavily dependent on the architecture of your data centre. If you have a server rack its performance is awesome. On distributed DCs, not so much. Agreed on what you say about the general ease of partioning on NoSql DBs --but reliability is a key concern. –  Apoorv Khurasia Nov 16 '12 at 21:03

MongoDB works well when you write a lot of data, and when your querying needs are not too complicated. Therefore, MongoDB is a good fit when you're implementing CQRS with Event Sourcing on the Command side -- i.e., your event store is a MongoDB database.

On the querying side, we still use a SQL Server db with views and WCF Data Services on top, because of its flexibility. I think in most cases you'll really need the power of a relational DB for querying.

share|improve this answer
If you write a lot of data won't global write locks negatively affect you? –  Apoorv Khurasia Nov 16 '12 at 21:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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