Another example of a database doing improper things would be Oracle mixing up the empty string with NULL. In Oracle, both are the same...
MySQL has a few more of those gotchas, e.g. regarding broken charsets (UTF-8 isn't 'utf8', it is 'utf8mb4', 'utf8' is an alias for 'utf8mb3' which is a broken subset). I wouldn't use MySQL for any data that was important to get back consistently. However, since Uber seems to be using some schemaless "we don't care"-layer anyways, that point is moot for the original article.
uft8mb4 uses more bytes than necessary for most. You get 255 varchar limits with uft8mb3, I think you only get 192 characters with uft8mb4.
utf8mb3 is definitely a broken subset, it's deprecated at the very least
Much of your MySQL complaint is not a MySQL issue, but a config issue.
And yes, powerful config options are good, not bad.
https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
"Hey, let's just not act transactional on a timeout by default"
This setting applies to lock-wait timeouts. The default value allows applications to decide on the correct course of action: either re-try just the statement that timed out (without having to re-do the previous parts of the transaction), or rollback the transaction.
The application still receives an error on the timeout regardless of this setting. The database doesn't automatically commit the previous statements in the transaction regardless of this setting.
How long are people going to keep repeating this complaint? Literally every version of MySQL and MariaDB that allows invalid dates by default (MySQL 5.6 and older, MariaDB 10.1 and older) has reached end-of-life for upstream support from the vendor!
MySQL 5.0 came out over 15 years ago.
It’s like asking you for an int and you entering 2.358 and saying that’s just simple.
MySQL: "2020-02-31? Whatever man, I'll just enter something..."