I've not interacted with mysql a whole lot, but when i did I was regularly surprised that it didn't have stuff I was missing from Postgres. Off the top of my mind:

- Query planner is much worse (just yesterday I had to USE INDEX to sped up a query by 300x, I'm near-certain postgres would just have gotten it right) - Indexes are much more limited: no GIST, no GIN - No transactional lock (`pg_advisory_xact_lock` in postgres). This one was very surprising, it's a really useful thing and I had to implement it myself as a lock table

MySQL had some problematic design decisions initially. They might be fixed now, but the impression remained. And later there was the added complication that they were bought by Oracle, so you didn't really know how this would turn out in the end.

PostgreSQL also had more features back then, e.g. the JSON support is very nice if you need to do anything that doesn't neatly fit into the relational model.

Maria, MySQL, Oracle shenannigans, perhaps.

Also postgres is a "proper" db, so I'm glad it generally won out.

Back in the day, the sentiment was the MySQL was more-performant but the criticized tradeoff of having "cut corners". I still remember when their transaction support InnoDB table engine came out. Anyway Postgres was viewed as slower but more standards compliant - so mature architects preferred that. MySQL, in my opinion, fell into default usage among LAMP stacks and PHP-using kiddies. Postgres took the crown over time.

MySQL was a proven solution back in the day, i.e late 2000s. Github/Twitter/Heroku etc were using it. In the past 10-15 years, Postgres has come a long way.

In the times when everyone was installing Apache + PHP + "Some database" stack, the easy path was to use MySQL for a very simple reason: it had ready to use MS Windows installer.

Another thing: those were times when web applications were practically 99% reads, and not so great ACID was a non-issue.

Postgres is OK, but it has really a lot of quirks that are not that obvious.