A bit late, but what I meant was that: With complex data but not too much of it, going all in on relational modelling makes development much easier, more relia

A bit late, but what I meant was that: With complex data but not too much of it, going all in on relational modelling makes development much easier, more reliable, and databases are perfectly capable of handling the necessary joins. With lots of data that isn’t too complex, denormalising a little and not using as many joins, or using a DBMS that doesn’t have joins and denormalising a lot (E.g. Redis, Cassandra, etc) will work well. Most problems are one or the other, or can be refactored into one or the other. At a previous job, we went hard on the relational aspect, and it worked well almost all the time. Inventory management, order management, user accounts, internal processes, etc. The main place it broke down was one table (out of ~450) of user content that due to the way the product worked, represented about 50% of our data. Working with that table became very hard. The right move would have been then to remove it and use a more appropriate DBMS, abandoning the heavily relational design for just that part.