When To Use NoSQL Document Databases: MongoDB, CouchDB

Why NoSQL Databases Were Invented

When traditional databases were introduced they were able to handle the size by running on bigger machines
NoSQL means that the database does not employ tables, rows and columns for data organization
Relational databases could horizontally scale which means being able to copy their data to other machines so reads could be distributed.
There was no easy way to distribute writes
To fix this problem, leading technological companies introduced new databases referred to as NoSQL.
Therefore NoSQL databases were designed to scale large datasets horizontally which means scaling large datasets was the primary motivator to create NoSQL databases.

Relationships are obvious using embedded arrays and documents.
The biggest benefit to developers of using a document-oriented database is that developers use structure like maps, hashes, dictionaries, and JSON objects.
The document model use a similar structure resulting in the representation that is easier and more natural, as it is the same in the code and the application.
This means there is no complex mapping between your applications data object and the database.
Today, we know that modern data sets can grow to be huge, that data is polymorphic by nature, and that our modern applications have to be resilient and always up.
NoSQL databases, and in particular a document-oriented database like MongoDB, are a more natural way to work with modern data.

Applications that take records that are fairly complex and need to access those records in a fairly complex way
Allows one to have a lot of records with a lot of engineering
Allows you to have different categories of data and access them the same way
For rapid application development
When you need a flexible schema

When the schema is easily changeable.
When you want to scale (especially horizontal): they are built for scale since their horizontal partitioning is inbuilt since they expect a lot of scale.
When you require simplicity e.g fewer tables, fewer relationships
When you want to aggregate data since they are built for aggregation

When you require to make a lot of updates since consistency is not guaranteed, the data may not be consistent (two nodes might have different data for the same ID)
They are not read optimized since they read each block and filter out the rows
They do not have implicit information of relations in data, therefore joins are hard if you have more than one table.