When you should have used Postgres

Highly relational data, where most entities are connected to most others and you query across those connections in ways you cannot predict, is what relational databases are for. Document stores make you choose your joins in advance by choosing your embedding, and $lookup exists but is not a substitute for a planner that has been optimising joins for thirty years.

Constraints are the underrated part. A foreign key means an order cannot reference a customer who does not exist, ever, no matter which service or script or midnight fix wrote it. A unique constraint means two concurrent requests cannot both create the same account, which application-level checking cannot guarantee because of the gap between your read and your write. These are guarantees the database holds even when your code is wrong, and code is sometimes wrong.

Transactions across several documents are the third thing. Mongo has them now, but the document model is designed so that you rarely need them, and if you find yourself needing them constantly that is the model telling you something. None of this makes Mongo the wrong answer: event logs, flexible product catalogues and rapidly changing shapes are genuinely nicer in it, but "I already know it" is not a design constraint, and picking a store because a tutorial used it is how teams end up rebuilding their persistence layer in year two.