Inno is the default for a backend *that requires transactions* and has been for a while. The assumption is simply that the most typical use of database will not require transactions -- which is probably true if you follow the mindset that a hash functions better as an api into a database. And, if your argument is on the lines of being informed costs too much time.. then just do us all a favor and remain silent.

MySQL has a pseudo-SQL interface into the DB which is more uniform for a new user. I'm also told from people that use MySQL replication that it is easier to manage -- and it works off the shelf without having to install a contrib module. MySQL still has more functionality in the CSV libraries. And, MySQL supported fts (without contrib modules) before pg. There are a ton of other things, like "AUTO INCREMENT" makes more sense than "serial" -- and if you give write access to a table in Postgres you assume you can insert into, but not if it has a serial datatype, because that creates a index. An Index is incremented on the write, therefore the index too has to be +w.

MySQL supports SQL extensions for mere convenience which Pg has a higher resistance to permitting. See "INSERT ignore INTO ...", "ON DUPLICATE KEY UPDATE", and