I've found this bias to be useful with two main exceptions:
1. It's nice if you can avoid using Postgres to store large files.
2. It's nice if you can avoid using Postgres for an event stream with massive volume (say billions of records per month that must be maintained and queried).
Postgres will work for either of these, but there are real advantages that come if you can keep your database lighter than these allow for.
An event stream / message queue implemented in PG can actually be fine at some billions of events per month and has some major advantages over standard queues. I just wouldn't get too high into the billions.
1. It's nice if you can avoid using Postgres to store large files. 2. It's nice if you can avoid using Postgres for an event stream with massive volume (say billions of records per month that must be maintained and queried).
Postgres will work for either of these, but there are real advantages that come if you can keep your database lighter than these allow for.