Honestly, as others pointed out, the multitude of sins of omissions that MySQL has performed over the years. For example, its silently ignoring the foreign key

Honestly, as others pointed out, the multitude of sins of omissions that MySQL has performed over the years. For example, its silently ignoring the foreign key constraints on certain database engines, such as MyISAM. On top of that, the repeated and continuing promises of actually implementing features like foreign keys in many of their database engines, including their high-performance NDB engine, means that the programmer has to do a lot more bookkeeping work on things that are built in on more rational databases. The multiple database engine mess leads to its own problems compared to engines like postgresql. Do you use the InnoDB engine, and rely on third-party products, like galera, for clustering, or do you use NDB and suffer its weaknesses in referential integrity, and difficulty in configuration? Finally, you get into issues where MySQL isn't nearly as featureful as PostgreSQL. For example, PostgreSQL supports a multitude of languages for creating server-side procedural functions -- pgsql, perl, python, tcl, etc, whereas MySQL only supports C, and only pre-compiled functions. This limits the utility, and leads to these quite useful features being left by the wayside because numerous coders were weaned on a database that didn't support doing these nice things for them. While mysql does have certain uses, I'd argue severely that postgresql is a much better designed foundation for working on new projects. The attention to detail, the emphasis on not eating your data, and the level of features means that you can spend more time coding, and in the language you want to use, and less time fiddling with your database software.