Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
It is web-scale /s – Froome Mar 24 '15 at 14:28
up vote 28 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:… – yati sagade Sep 19 '11 at 14:01
@yati: That kind of application sounds similar to 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

Databases like MongoDB are great when you usually know where your data is(as opposed to needing to write several complicated queries). With Mongo, "related" data is either nested in the parent data or it has primary/foreign keys. This is great if, for example, you have Posts and Comments; generally, you aren't going to be displaying comments outside the context of a post, so it makes sense that comments be contained within a post(that way you get all the comments for the post without needing to query a separate table).

MongoDB is schemaless. This means that it will take whatever structure of data you throw at it, for the most part.

On the other hand, if you are need to use aggregate functions and feel the need to query data in complex ways that cannot be achieved through embeds or simple relations in Mongo, that's when you know it's time to use a RDBMS like MySQL or PostgreSQL.

MongoDB isn't meant to replace SQL. It simply fulfills different needs, and MongoDB and an RDBMS can be used in conjunction. In my opinion, MongoDB isn't all that necessary if you don't need your data to be flexible or embedded in a parent document. Development with MongoDB is very fun because there are far fewer steps involved in getting a project(say in Rails) up and running. Need to make a change? No problem. Just add an attribute to your model. Done.

I can't speak for many other NoSQL databases, though I know that they are usually similarly designed to fulfill a specific need that cannot be met by an RDBMS. Some reside entirely in memory or are able to be sharded or scaled very easily. I'm pretty sure that Cassandra is designed to continue operating without data loss if a node goes down. Redis is basically a key value store that resides in memory(with periodic disk writes for persistence), but also has the ability to store data types like sets and sort them.

share|improve this answer

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
Note that Mongodb no longer uses a global write lock (and had already been updated to not require one when the above comment was posted). – Jules Sep 3 '15 at 1:26

The immediate and fundamental difference between MongoDB and an RDBMS is the underlying data model. A relational database structures data into tables and rows, while MongoDB structures data into collections of JSON documents. JSON is a self-describing, human readable data format. Originally designed for lightweight exchanges between browser and server, it has become widely accepted for many types of applications.

JSON documents are particularly useful for data management for several reasons. A JSON document is composed of a set of fields which are themselves key-value pairs. This means each JSON document carries its own human readable schema design with it wherever it goes, allowing the documents to easily move between database and client applications without losing their meaning.

JSON is also a natural data format for use in the application layer. JSON supports a richer and more flexible data structure than tables made up of columns and rows. In addition to supporting field types like number, string, Boolean, etc., JSON fields can be arrays or nested sub-objects. This means we can represent a set of sophisticated relations which are a closer representation of the objects our applications work with. Using JSON documents in our database means we don’t need an object relational mapper between our database and the applications it serves. We can persist our data in the right form

share|improve this answer

If your data needs lots of querying then a NoSQL solution is not good and when you need transactional support (ACID) then a NoSql is not the best fit. I think NoSQL shines when you have a lot of reads which needs to be fast and when the structure is somewhat adhoc, you retrieve by document or by page structure, something like that. But a lots of NoSQL-solutions improves a lot quite fast so there shortcomings maybe soon will be gone. Anyway I think relational databases are still a good fit for most applications.

share|improve this answer

protected by gnat 6 hours ago

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?