Postgres has lots of shiny features on the SQL side, but MySQL's storage and especially replication has always been more reliable for me. I've seen a couple failed MySQL -> Postgres migrations because it's the shiny thing people chase, but the operational reality is that MySQL is still better.
That's why I listed both. I'd use and recommend Postgres as a default in a heartbeat based off personal experience, but I wouldn't have personal experience with MySQL's strengths and people use and recommend it as well.
Postgres has gotten better and friendlier over time, but its still much easier to ramp up with MySQL.
Postgres certainly wins in terms of features, though most of those features aren't required by the vast majority of web apps, so "more features" isn't necessarily a reason for most people to favor Postgres by default. Which features of postgres which aren't present in MySQL would you not want to live without?
You also called MySQL a toy in terms of stability compared to Postgres. What experiences shaped this opinion?
For an anecdote, I work at a relatively large SaaS company which runs over 300 MySQL servers in production, over 600 if you include QA. We specifically run percona-server because it's basically the enterprise version of MySQL, and percona makes some great tools. (We use the free version of percona and do not pay for percona support). We have a single DBA who manages all of those servers full time. I work in ops/SRE and touch MySQL here occasionally, but mostly just to touch the OS, monitoring systems, automation systems, etc on those machines. So overall, our ratio of admins to MySQL servers is basically 2:600, which makes me consider it not a toy (especially in comparison to the number of people it take to manage the other data services we run). As far as stability goes, we were rock solid on MySQL 5.6, but hit a few serious bugs on MySQL 5.7 (two memory leak bugs in plugins, and one in the core that caused a crash), all of which have been resolved as of 5.7.12. 5.7 is an extremely major release in terms of features and performance, so I'm willing to let a few bugs slide here.
We run many different types of data services, mysql/hadoop/hbase/kafka/redis/zookeeper/elasticsearch/etc, adding postgres to the mix has always been of interest to some devs who want a postgres feature here and there. I personally like both MySQL and postgres, but it seems that MySQL may be more mature in terms of operations (tooling and replication/HA) and performance. I love ops work, so to me, more services means more fun and I've advocated to add postgres in the past, but it's tough to find reasons to push for it.
Unfortunately, now I've gotten away from the topic of "boring" stack to use, but in general, I think the choice for a "boring" database would be MySQL, while postgres is shinier and more advanced. There are a lot more people using MySQL in the wild and virtually every language and framework supports it. I typically view postgres as a more hip open source database, due to its interesting features and niche of developers who really really love it, whereas MySQL is the popular option, that gets the job done, and mostly lacks enthusiastic supporters. People just use it because it's easy and works. That said, it's easy to see how people could have different opinions on which of these is the "boring" choice because both are perfectly reasonable choices. When not operating at a big scale, mostly default installations of both MySQL and postgres will get you quite far and are pretty comparable to manage.
Here's a few:
1. Check constraints.
2. INTERSECT and EXCEPT operators.
3. Common table expressions.
4. Sort-merge join.
5. Serializable snapshot isolation.