SQL is a relational database in the sense that it uses a unique collection of tuples. Simply an ordered collection of values.

A relation is represented as a table. and each tuple makes up a row in the table. This definition of tables and rows is called a schema.

This has pros and cons. You will know the entities and values that your application will expect; but on the other hand, it’s not good in dealing with dynamic data. The ID field must be unique and not be NULL/empty. All this will make your data reliable.

NoSQL: you might still find some SQL within it! It just means that it’s ‘not only’ SQL! In these databases, they sacrifice some robustness in order for greater speed and scalability. One of the most popular forms is a document store. There is no schema and normalization. You simply have a collection of whatever you put in (so it’s easy to make a mess of things!).

But this will work better with dynamic data. It can also run on multiple servers, while SQL is typically tied to one server. You’re not dealing with field validations, so it’s really fast. MongoDB and Firebase are two key examples of this!

Graph databases → used for something like Facebook or Instagram, for heavily relational data like nodes and nodes of friends. This runs a lot faster than if you were trying to do this with another type of database.

Key-value stores → key-value pairs. Could be good for caching or storing data.

Wide-column data stores → Instead of holding access to a single value, a key holds access to an entire column. Can hold a lot of data. Can be used for a lot of things: from financial data to internet of things.

There are also some newer SQL databases that have fancier options to help with lookup. Can filter using queries. If you’re interested, these are NewSQL databases.