Overview of NoSQL Database

As in today's world we have seen that everything will be data. All processed transactions are online Social Media that are a part of everyone's life. Every second there is lots of data created. Everything is data but relational databases are not scalable enough for the high volume of data. To satisfy the needs of the high volume of data there is another kind of database called “No SQL” database, so in the following article I am trying to provide you an overview.


No SQL (Not Only SQL) databases are non-relational databases designed to handle a large volume of data. It's a next generation of databases and a paradigm shift from relational databases.

Benefits of No SQL

  • Easily handles a large volume of data.

  • Highly scalable, easily supports scale out and Horizontal Scaling.

  • It doesn't depend on the format of the data. Supports all kinds of data, like structured, semi-structured and unstructured.
  • Open-source.

  • Well integrated with Object Oriented Programming.

  • Very well support by clouds.

Types of “No SQL” databases


    Key-Value databases

    This is the simple type of No SQL database that stores the data in a hash table format. Every item has a unique key that points to the data.

    Examples: Riak ,Voldemort , Redis

    Document Database

    This is also based on a key/value pair but in the value it stores the JSON for the kind of document. Documents can contain many key-value pairs, or key-array pairs, or even nested documents.

    Example: MongoDB, CouchDB

    Column family store: This type of data works for large datasets and stores the data in columns instead of rows.

    Examples: CouchDB, MongoDb

    Graph Database

    Graph DB stores networks, such as social connections.

    Examples: Neo4J ,InfoGrid

Myth about No SQL

Everybody is thinking that No SQL is a replacement of relational databases.


No SQL is not a replacement, it's an alternative way of storing data. In some kinds of applications “No SQL” is not supported so relational database is well suited.


  • Lack of maturity
  • Not well-supported for highly transactional databases

Similar Articles