NoSQL databases have a lot more to offer than just solving the problems of scale

which are mentioned as follows:

Schemaless data representation: Almost all NoSQL implementations offer
schemaless data representation. This means that you dont have to think too
far ahead to defie a structure and you can continue to evolve over time
including adding new filds or even nesting the data, for example, in case of
JSON representation.
Development time: I have heard stories about reduced development
time because one doesnt have to deal with complex SQL queries. Do you
remember the JOIN query that you wrote to collate the data across multiple
tables to create your fial view?
Speed: Even with the small amount of data that you have, if you can deliver
in milliseconds rather than hundreds of millisecondsespecially over
mobile and other intermittently connected devicesyou have much higher
probability of winning users over.
Plan ahead for scalability: You read it right. Why fall into the ditch and
then try to get out of it? Why not just plan ahead so that you never fall into
one. Or in other words, your application can be quite elasticit can handle
sudden spikes of load. Of course, you win users over straightaway.

Comparing the models

Transactional application
For a transactional application, NoSQL can help as follows:
Column-oriented database helps defie structure. If need be, it can be
changed over time.
Document-oriented database can help implement JOIN or create views.

Using NoSQL will result in a few limitations for a transactional application:

Inability to define relationships
Absence of transactions (Neo4j is an exception)
Unavailability of ACID properties in operations (CouchDB and Neo4j are
the exceptions)
Using Cassandra or CouchDB can be overkill if we compare them to, for
example, MySQL or PostgreSQLthey do not unleash their true power
in a single-machine installation
Absence of support for JOIN and cross-entity query, though
documentoriented stores support it by way of MapReduce but the efforts
may be
substantial as the queries get comp

Decision
Choose RDBMS rather than NoSQL. The disadvantages outweigh the advantages.

Engine types

Limits
Cassandra: All data for one row must fi in one physical disk. Each column
value should not be larger than 2 GB (231 bytes). Maximum number of

columns per row is 2 billion (2 x 109), implying that each record may be no
larger than 262 bytes. The column name has an additional limit of 64 KB.
See the offiial documentation on limitations at http://wiki.apache.org/
cassandra/CassandraLimitations. Note that versions prior to 0.7 had
smaller limitations.
CouchDB: Interestingly, the offiial document at http://wiki.apache.
org/couchdb/Frequently_asked_questions#How_Much_Stuff_can_I_
Store_in_CouchDB.3F says that the practical limits are unknown (read:
never hit till date). Another discussion at http://stackoverflow.com/
questions/11019360/couchdb-document-size-limits points that the
confiuration puts a limit of 4 GB, but again that may only be a default limit.
Neo4j: Documentation says that theoretically there are no limits. The default
limit values are imposed only because of the typically available hardware.
See http://docs.neo4j.org/chunked/stable/capabilities-capacity.
html#capabilities-data-size for details.
Redis: String value is limited to 512 MB while the upper limit on the size
of the value for a key in general is 2 GB. Read http://redis.io/topics/
data-types for details.

Bulk operations
operations that involve multiple entities in a single go
Database

Supported

Example

Bulk operations
operations that involve multiple entities in a single go

Read
Database

Supported

Example

Supported

Example

Supported

Example

Insert
Database

Delete
Database

Query options
Composite indexes

Views

Security
Authentication
Database

Supported

Availability

Maintenance

Tools

Source and license

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
Getting Started with NoSQL