Today there are numerous database systems and concepts, each with their own advantages and disadvantages, its own optimizations and cavities. This document will briefly explore 3 popular database types: relational (e.g. MySQL), document-based ("noSQL", e.g. MongoDB) and Graph (not to be confused with GraphQL which is a different concept, not-related to this article) (e.g. neo4j)

Relational DB (RDBMS)

SQL stands for Structured Query Language, and is actually the language used to communicate with RDB systems. Relational DBs are, as their name suggests, based on relations. In RDBMS data is usually stored within tables, where each column has a fixed, predefined data-type. Some columns in a table can be marked as "foreign keys" - which "points" to different key columns in a separate table. For example, you could have a table that represents data for books: you will probably have columns such as "title", "publish_date", "genre", along with a unique id for the table, and you will probably also want to save data about authors - this will be saved in a different table, with data columns such as "name", "date_of_birth", along with a unique id column for each author. Now, what if you want to obtain the books data, together with the authors data? You can have another column in the books table: author_id, which will be defined as a "foreign key" for the id column in the authors table. Now you can easily obtain a "joined" data view, showing the names of the books together with the data of each author. You might also want to separate information about genres into a new "genres" table, the genre table could have an "author_id" foreign key, as well as a "book_id" foreign key, and you could then join the data for the three tables in different ways.

To conclude: use relational databases when you know you'd want to have your data parts "separated" and be able to make dynamic connections and joins between the different parts of data.

Document-Based (e.g. MongoDB) -

The data structure in document based DBs is based on "documents", a series of keys and values enclosed within curly brackets. This data structure is very similar to JSON and Javascript Objects - and therefor it allows lower "overhead" when transferring the data to a Javascript applicative layer. In document-based DBs, the data types of each data are not strict, you may choose different kinds of data types to different documents in the same collection (in practice, though, there is usually some form of "schema" regulated upon data collections). In document based DBs you can have data "nested" within another data. For example, suppose you have a collection of Posts, then you want to save "comments" for each post - you can have a "comments" data key on each post document, which will contain an array of comment objects. This is useful if you know you'd always need to get "comments" along with "posts" - and you'd rarely want to get the "comments" data together with another collection.

To conclude: Use document-based DBs when you know that your data structure will be built in such away where different data parts rely on the same other data parts, and that the relations between them are expected to be constant (e.g. Posts have Comments).

Graph Based (e.g. Neo4j)

The final DB type is graph based DBs. In these kind of DBs - the relations between data nodes are also saved and persisted as part of the data itself. This is useful when you want, for example, to save data representing a tree - and so you could save relationships such as 'X is a child of Y', 'J is a parent of O' and so on.