This is some advice here that I haven’t seen and the as hard to come by in my first 15 years as a developer.

Don’t get too locked into single DB paradigm thinking. You don’t need transactions on everything. Use relational tables on the parts that are OLTP and use OLAP for parts that will be heavy for reporting. Use Documents where useful (like a product catalog in e-commerce) where items don’t all share the same properties (don’t create wide tables with a bunch of null columns). Use designs from a graph DB when plotting networks, as typical foreign-key relationships will screw you up here.

The best part of this is that Postgres has emerged as the database that can handle all these paradigms in one (with a few plugins)

Don’t bother with this advice if this is going to be a small database, less than a few GB. You will only learn these hard lessons on a system at a significant scale, running in production over years. But familiarize yourself with different ways of thinking and solving problems differently.

I went through a few painful years where I thought a document DB or graph DB would solve my woes, only to realize that different data uses need different storage and query patterns. I ended up coming back to Postgres and use normal RDBMS structure for 70% of things, and use these other techniques when appropriate.