Thanks for the link and input. Any reason a team already more familiar with Postgres than MySQL would go for the latter in this case, is MySQL somehow more suit

Thanks for the link and input. Any reason a team already more familiar with Postgres than MySQL would go for the latter in this case, is MySQL somehow more suited for such scenario? Or your just mean "just pick a RDBMS", so choice of MySQL over Postgres over let's say CockroachDB (which should be a drop-in replacement for Postgres if-and-only-if you stay away from fancier Postgres features like array and JSON fields, stored procedures etc...) is not your point? (As context, I tend too to pick a RDBMS in general, and Postgres in particular, but I saw projects where there was a huuuge impendance mismatch between the business logic and the relational model, data was simply unimaginably awkward to think of it in a relational model and manipulate it as such, it was all trees in trees in trees, mongo/couch model all the way and mongo was boring enough to be a good fit there.)