I'm a bit confused about the whole NoSQL thing and such. When would you choose to use something like MongoDB over something like Oracle or MySQL? I don't really understand the "difference" as far as usage goes between them.

From my understanding NoSQL type databases aren't meant to replace RDBMSes, but what exactly are they meant to do?


9 Answers 9


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

  • 50
    Your first two examples sounds like a good domain for a traditional Relational DBMS.
    – Jonas
    Commented Jul 8, 2011 at 10:57
  • 7
    @yati: That kind of application sounds similar to StackOverflow.com and I find it works very good with a traditional relational database.
    – Jonas
    Commented Sep 19, 2011 at 14:08
  • 4
    @yatisagade: I we are not talking about dynamic social sites. But a little note taking app and a micro blogging system.
    – Jonas
    Commented Sep 19, 2011 at 14:56
  • 6
    How is not having a defined schema ever a plus? With a relational DB, if three months down the line you need an extra field, you just add the field. With a relational DB you can't add a field dynamically but you also can't change your application code dynamically to work with a dynamically added field. Commented Jun 6, 2016 at 21:20
  • 30
    This answer seem to suggest the schema of a relational database cannot be changed. I am unable to comprehend what amount of misunderstandings which might lead someone to believe this. It is trivial to add a new column in a relational database. Typically there is a nice UI, or if you prefer to script it, it can be done in a single SQL statement.
    – JacquesB
    Commented Dec 12, 2016 at 15:04

Sorry to add another answer but none of the answers here are very satisfactory. This answer is specific to MongoDB (as opposed to the vast array of other data storage options out there which are not relational databases).

Update (July 2020)

Every now and then this answer gets a vote and I get a pang of guilt because I've felt for a while it has grown into a stale answer. For one thing, MongoDB supports multi-document transactions now which throws into question a fair number of the points I've brought up. I haven't used it for performance in depth since they added these transactions so I cannot comment on that.

Furthermore, I have recently been working with unstructured data and the schemaless property of MongoDB has been more of a benefit than the below answer might suggest. For example, I am working with test result data generated by a testing & execution solution. The test cases themselves (and thus the different result columns) are created by the end user. MongoDB allowed me to store the free-form test results, in a way that is searchable, without needing a strict schema. I will re-emphasize my point on migration though. Every time the users make a change to their test cases the tools they are using to analyze their results also has to change.

As an alternative, SQL based storage engines have strengthened support for free-form columns such as Postgres' JSONB data type or MySQL's JSON data type.

Take Away: Today, the differences between mongodb and an SQL database feel more and more like the differences between Java & C# or maybe Node & Java. Both have their zealots that will feel the decision is obvious. They both obviously do things differently under the hood. However, at the end of the day its hard to declare either one superior or even to identify broad situations that favor either one.

If you are struggling to make this choice then pick the one that most appeals to you. Keep in mind that any data solution is likely to need to be revisited and rewritten continuously as your application scales up. By then you will understand your storage needs more and will likely be looking for a very tailored critical section / use case.


  • MongoDB has a lower latency per query & spends less CPU time per query because it is doing a lot less work (e.g. no joins, transactions). As a result, it can handle a higher load in terms of queries per second and is thus often used if you have a massive # of users.
  • MongoDB is easier to shard (use in a cluster) because it doesn't have to worry about transactions and consistency.
  • MongoDB has a faster write speed because it does not have to worry about transactions or rollbacks (and thus does not have to worry about locking).
  • MongoDB does not have a schema in case you have a special use case that can take advantage of that.


  • MongoDB does not support transactions. This is how it obtains most of its benefits.
  • In general, MongoDB creates more work (e.g. more CPU cost) for the client server. For example, to join data one has to issue multiple queries and do the join on the client.
  • Even here in 2017 there is less tooling support for MongoDB than there is for relational databases simply because it is newer. There are also fewer MongoDB experts than their relational counterparts.

Points Often Misunderstood:

  • Both MongoDB and relational databases support indexing. Their query performance is similar in terms of executing large queries.
  • MongoDB does not remove the need for migrations or more specifically, updating your existing data as your schema evolves. For example: If you have an application that relies on a users table to contain certain data, and you modify that table to contain different data (let's say you add a profile picture field), then you will still need to either:
    • Write you application to handle objects for which this property is undefined OR
    • Write a one-time migration to put in a default value for this property OR
    • Write code to provide a default value at query time if this field is not present OR
    • Handle the missing field in some other way
  • 6
    I'd add a huge thing, that is somehow missed in many NoSQL vs RDBMS discussion: NoSQL databases are much harder for ad-hoc querying (that's the "no SQL part". This is true whether you are a developer or not. Therefore, they are also much harder to create reports with, which is crucial to any serious business.
    – Michael
    Commented Nov 15, 2017 at 11:36
  • Heh, I'd almost call that a feature for MongoDB as I discourage that kind of interaction with my databases. However, Mongo does have an ad-hoc query language and a graphical ad-hoc client (Compass). It isn't as feature rich as SQL so I will agree it is a potential shortcoming but for me personally, it will never make a difference when I am deciding which database to use.
    – Pace
    Commented Nov 15, 2017 at 16:16
  • 2
    Why would you discourage exploring the data in your database? If this database has any useful information for the business, it ought to be as accessible as possible. Obviously while not adding load unto production, that's what you have read replicas for.
    – Michael
    Commented Nov 15, 2017 at 20:24
  • 1
    Eventually you will always have stakeholders that are interested in looking at the data. Whether it's via a SQL query or some kind of ipython notebook script, or via re:dash. So when you make database changes, you will always have to make sure you don't break these dependencies. SQL (not RDBMS) makes the data more accessible, and for a that's a good thing for a business.
    – Michael
    Commented Nov 16, 2017 at 12:14
  • 2
    This comment is now outdated. MongoDB supports outer joins as of 3.2 and transactions as of 4.0.
    – dimiguel
    Commented Jun 8, 2019 at 9:27

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

Using RDBMS's instead of other types:

  • 4
    "RDBMS's make heavy use of indexing for performance" Isn't indexing used with MongoDB as well?
    – Rotareti
    Commented Oct 19, 2016 at 15:41
  • When to use MongoDB or other document oriented database systems? currently deleted on SO... no more .. have reopened the question as well protected it. Not sure the reasoning behind deletion.
    – Rahul
    Commented Mar 20, 2017 at 14:07
  • If you are using indexing for performance and it adversely affects performance then you are not using indexing for performance!
    – Steve Kidd
    Commented Jul 25, 2020 at 14:50

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.


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


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.

  • 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
    Commented Nov 16, 2012 at 21:03
  • If you do a lot of writes you may simply have 2 models: a denormalized stronly indexes read model AND an unindexed write model. Naturally replication is needed which adds complexity. You'll have to evaluate what is more disadvantageous for you: coping with NoSQL limitations i.e. do a lot more programming work yourself to match records in the java domain, or have existing DB replication technology do the work or you which will cost more on terms of configuration and hardware.
    – Lawrence
    Commented May 15, 2017 at 13:46

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.

  • If you write a lot of data won't global write locks negatively affect you?
    – Apoorv
    Commented Nov 16, 2012 at 21:01
  • 1
    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
    Commented Sep 3, 2015 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


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.