Last Updated:

Databases per use type

The critical difference between NoSQL and Relational databases is that RDBMS schemas rigidly define how all data inserted into the database must be typed and composed, whereas NoSQL databases can be schema agnostic, allowing unstructured and semi-structured data to be stored and manipulated.


NoSQL databases emerged as a popular alternative to relational databases as web applications became increasingly complex.

Advantages: Since there are so many types and varied applications of NoSQL databases, it’s hard to nail these down, but generally:

  • Schema-free data models are more flexible and easier to administer.
  • NoSQL databases are generally more horizontally scalable and fault-tolerant.
  • Data can easily be distributed across different nodes. To improve availability and/or partition tolerance, you can choose that data on some nodes be “eventually consistent”.

Disadvantages: These are also dependent on the database type. Principally:

  • NoSQL databases are generally less widely adopted and mature than RDBMS solutions, so specific expertise is often required.
  • There are a range of formats and constraints specific to each database type.

NoSQL/Non-relational databases can take a variety of form:

Time-Series database

InfluxDB, AWS Timestream, Informix, Prometheus, Riak-TS, RRDTool, M3db, eXtreme

A software implementation that is optimized for handling time series data, arrays of numbers indexed by time, a datetime or a datetime range. In some fields these time series are called profiles, curves, or traces. This kind of databases allows users to create, enumerate, update and destroy various time series and organize them. The server often supports a number of basic calculations that work on a series as a whole, such as multiplying, adding, or otherwise combining various time series into a new time serie. They can also filter on arbitrary patterns such as time ranges, low value filters, high value filters, or even have the values of one series filter another

Key-Value Stores

Redis, AWS DynamoDB, Memcached, Aerospike, Riak-KV, Tarantool

Are extremely simple database management systems that store only key-value pairs and provide basic functionality for retrieving the value associated with a known key. The simplicity of key-value stores makes these database management systems particularly well-suited to embedded databases, where the stored data is not particularly complex and speed is of paramount importance.

Wide Column Stores

Cassandra, Scylla, HBase

Are schema-agnostic systems that enable users to store data in column families or tables, a single row of which can be thought of as a record, a multi-dimensional key-value store. These solutions are designed with the goal of scaling well enough to manage petabytes of data across as many as thousands of commodity servers in a massive, distributed system.

Document Stores

MongoDB, Couchbase, CouchDB, Firebase,

Are schema-free systems that store data in the form of JSON documents. Document stores are similar to key-value or wide column stores, but the document name is the key and the contents of the document, whatever they are, are the value. In a document store, individual records do not require a uniform structure, can contain many different value types, and can be nested. This flexibility makes them particularly well-suited to manage semi-structured data across distributed systems.

Graph Databases

Neo4J, Datastax

Represent data as a network of related nodes or objects in order to facilitate data visualizations and graph analytics. A node or object in a graph database contains free-form data that is connected by relationships and grouped according to labels. Graph-Oriented Database Management Systems (DBMS) software is designed with an emphasis on illustrating connections between data points. As a result, graph databases are typically used when analysis of the relationships between heterogeneous data points is the end goal of the system, such as in fraud prevention, advanced enterprise operations, or Facebook’s original friends graph.

SQL / RDBMS / Relational

MySQL, MariaDB, PostgreSQL, SQLite, Oracle, MS SQL Server, IBM DB2

Relational databases emerged in the 70’s to store data according to a schema that allows data to be displayed as tables with rows and columns. RDBMS all provide functionality for reading, creating, updating, and deleting data, typically by means of Structured Query Language (SQL) statements. The tables in a relational database have keys associated with them, which are used to identify specific columns or rows of a table and facilitate faster access to a particular table, row, or column of interest.

Data integrity is of particular concern in relational databases, and RDBMS use a number of constraints to ensure that the data contained in the tables is reliable and accurate.


  • Relational databases are well-documented and mature technologies, and RDBMS are sold and maintained by a number of established corporations.
  • SQL standards are well-defined and commonly accepted.
  • A large pool of qualified developers have experience with SQL and RDBMS.
  • All RDBMS are ACID-compliant, meaning they satisfy the requirements of Atomicity, Consistency, Isolation, and Durability.


  • RDBMS don’t work well (or at all) with unstructured or semi-structured data, due to schema and type constraints. This makes them ill-suited for large analytics or IoT event loads.
  • The tables in your relational database will not necessarily map one-to-one with an object or class representing the same data.
  • When migrating one RDBMS to another, schemas and types must generally be identical between source and destination tables for migration to work (schema constraint). For many of the same reasons, extremely complex datasets or those containing variable-length records are generally difficult to handle with an RDBMS schema.