Database Type: Relational

There is no database type that is inherently better than an other. They all exist because they fulfill a particular need. Let's take a simple example to compare the 3 most common paradigms: relational, document, and graph databases.

Let's say you want to represent pet Owners and their Pets in a database. You can do that in either a relational, document, or graph database, however, the way you serve and manipulate this data will affect the decision of which type to use.

Document Database

If your app is more about owners than pets, you can embed a pet directly into an Owner document. It would look something like this:

[
  {
    "id": "sven-id",
    "name": "Sven",
    "pets": [{ "name": "Tom", "favorite": true }, { "name": "Jerry" }]
  }
]

In this case you only have 1 collection, Owners. Maybe you are making a dating website and the data about pets is just kind of extra information. You only have owner profiles.

A document database typically has a flexible structure. As you can see Tom has a favorite attribute, but not Jerry. This flexibility is a double-edged sword though, and can lead to inconsistent data.

Document databases are appreciated for their simplicity. In a sense, they are like storing directly a JavaScript object in a database. If those collections of objects you are storing don't need to interact with other collections, it is a fast way to get up and running. For instance if I were to make a chess game, I would probably use a document database to store the board data.

Relational Databases

Now let's say that we are making a website where we have both owner profiles and pet profiles. Maybe we want to show a whole bunch of information about the pets, like their race, favorite toys, etc. The database tables would look something like this:

[
  {
    "id": "sven-id",
    "name": "Sven"
  }
]

[
  {
    "id": "tom-id",
    "name": "Tom",
    "favorite": true,
    "ownerId": "sven-id"
  },
  {
    "id": "jerry-id",
    "name": "Jerry",
    "favorite": false,
    "ownerId": "sven-id"
  }
]

A relational database would connect owners and pets via a foreign key (ownerId). This way we can query Owners alone, Pets alone, but also perform joins and retrieve Owners and Pets in a single query. Note that joining this data together would give us the same result as the document example above, except that the data is stored in a normalized (flat) way, meaning that there is no nested object and everything is its own thing.

Note that it is also possible to store nested objects in relational databases that support JSON fields, giving us the best of both documents and relational worlds.

As you can see, Jerry also has a favorite field here, because relational databases enforce a strict structure that all entities within a table must follow.

Relational databases have been the standard for decades, because they can handle very well the most common cases of data. They shine when you want a strict integrity and if you regularly join tables together.

Graph Databases

Let's say that we now want to represent the friendship between owners, and which pets like to play together. In this situation, the relationship between each entity becomes essential. Let's take this example:

You could use a few relationship tables in a relational database to connect entities together, like this one:

[
  {
    "ownerId": "sven-id",
    "petId": "tom-id"
  },
  {
    "ownerId": "david-id",
    "petId": "jerry-id"
  }
  {
    "ownerId": "marc-id",
    "petId": "spike-id"
  }
]

And it would work fine for simple queries with a few joins. However queries become more and more complex as you travel deeper into the relationships. That's why graph databases exist. They make querying through a complex graph much easier. For instance, here is a query for the Neo4j database that retrieves the pets that Sven's pet likes to play with, AND their pet friend:

MATCH (:Owner {id: 'sven-id'})-[:OWNS]->(:Pet)-[:LIKES_TO_PLAY_WITH*1..2]->(p:Pet)
RETURN p.name

This returns Jerry and Spike. This could be used as a recommendation that Tom should play with Spike too, since it's a friend of a Jerry.

This kind of database is used heavily in social networks, recommendation engines, or fraud detection.

FaunaDB

There is also FaunaDB, which is a flexible multi-model database that does it all, documents, joins, graphs, and more. It's ACID-compliant, can be modeled with GraphQL schemas, all in a decentralized serverless environment. Sounds too good to be true! Well yes, because there is a catch. It's not exactly a database, it's a cloud service that you interact with with an API. You can't self-host it. So if you like to own your data, to deploy it in whatever way you want, that won't work for you. But it's an alternative worth mentioning.

---

Personally, for the most common use cases, if I don't need the flexibility or simplicity of document databases, and if I don't think my data will be so interconnected that it will require a graph database, I will pick a relational database.

Might change soon?

Possibly