Title: Hi,<p>I&#x27;ve been recently exposed to some informational systems where all the domain data was modeled as one graph instead of a set of inter-related tables.<p>I worked with RDBs (primarily Postgres) for 5+ years and I cannot say that it ever felt wrong, but the more I think about modeling data as graphs, the more it makes me confused why it&#x27;s not the default way.<p>Graphs seemed to be:
(1) Easier to scale (both storage-wise and complexity-wise).
(2) Closer to how we model the world in our minds, hence easier to reason about.
(3) Easier to query (felt more like GraphQL than SQL if it makes any sense).<p>The way I see it, there are two major ways to connect singular entities in a data model:
1. Lists (aka tables) that allow you to sort, filter, and aggregate within a set of entities of the same kind.
2. Relations (aka graph edges or foreign keys) to connect singular entities of different kinds.<p>... And I can imagine relational DBs being List-first Relation-second, and graph DBs being the opposite. But maybe that&#x27;s too much of a simplification.<p>Anyway, looking back at different domains I worked with, it felt like I had spent much more time working with relations than with lists.<p>Another signal: I have an intern developer, and it took him 1 minute to understand the basics of how graphs work, but then I spent two hours explaining why we needed extra tables for many-to-many relations and how they worked.<p>Any thoughts? What am I missing? Are RDBs the default way mostly due to historical reasons?<p>Discussion on this topic that I could find: https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27541453
Upvote: