MySQL is a great example how extreme commitment to backwards compatibility makes your whole product backwards.<p>It is chock full of bugs and footguns that you can work around and mitigate if you know how to configure it correctly, but most of those improvements are still not the default.<p>And the `utf8` encoding, that does not fully support UTF-8 looks like it’ll stay around forever. ಠ_ಠ<p>As the author of the post says, much better to just use PostgreSQL, will save you a lot of headaches down the road.
previous discussion: <a href="https://news.ycombinator.com/item?id=17310690" rel="nofollow">https://news.ycombinator.com/item?id=17310690</a><p>additional context (which the OP didn't reference):<p><a href="https://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-over-utf8mb4/" rel="nofollow">https://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-ov...</a><p><a href="https://mysqlserverteam.com/sushi-beer-an-introduction-of-utf8-support-in-mysql-8-0/" rel="nofollow">https://mysqlserverteam.com/sushi-beer-an-introduction-of-ut...</a><p><a href="https://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb3.html" rel="nofollow">https://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8...</a><p>hint: "Exactly the same set of characters is available in utf8mb3 and ucs2."
"Never" seems an odd choice. Until somewhat recently the recommendation would have been the now-deprecated "utf8mb3" for which "utf8" is a synonym.<p>Until the next release, when "utf8" is updated to be a synonym for "utf8mb4", yes, use "utf8mb4" directly. At the next release, you can use "utf8" again.