What database should I use?
Nowadays, there are a lot of different databases. They all function extremely differently, so it can be tricky to know what database would suit a specific project best. This aim of this article is to be a quick and easy way to compare different databases, and see which one would work best for you.
Relational vs Nonrelational
Relational databases are the ‘old school’ databases, like SQL. Non relational databases are the ‘trendier’ databases, such as MongoDB. Relational databases are stored similarly to an Excel spreadsheet, with a value corresponding to a row and a column. Non-relational databases does not store data in the tabular method (how the data is actually stored varies by database). Because the data is stored differently, it effects the speed, scaling, and complexity of the database. If your data would fit well in a table, then you most likely would want a relational database. When choosing between a relational or nonrelational database, the most important question to ask is Do I care about the relations between the data? An example of this is a system that uses lots of joins to combine rows from multiple tables.
Different types of NRDBs
There are a lot of different types of nonrelational databases. A whole lot. They all function in very different ways, from the way one can store data, from the type of data that can be stored, to the difficulty in setting up the database. I would recommend using this chart to get an overall view of different types of NRDBs, but you’ll definitely want to read a little bit more into the architecture of the different systems.
NRDBs usually split up the data, and stores it in different, individually scalable areas, rather than keeping it all together like in a relational database. As the database grows, RDBs will keep data in the same tables together, while NRDBs will take the data and break it up, while attempting to keep data that is often accessed at the same time together. While the database is typically very scalable and there usually is not one single point of failure, there are downsides, such as very expensive joins.
An important theorem used in NRDBs is the CAP theorem — Consistency, Availability and Partition Tolerance. It is believed that in a NRDB, tradeoffs need to be made between these three categories. So a very available system would also have a very low consistency.