In MySQL, use “utf8mb4” instead of “utf8” (2016)

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by lewiscollard on Wednesday January 12, 2022 @01:29PM (#29910911)

In the WordPress world, it is the only database.[0] If you do WP, you do MySQL. You may sniff at WP (I certainly do), but it is used for 43% of all websites, which is not a trivial number of deployments, and not a small market.

I suspect it has a large market share in the "started as a trivial PHP program, grew to large application, too committed to MySQL to migrate to something else" market, too. There's that one website with the blue F logo that went this path, but there's probably thousands more.

That's not the same thing as anyone actually preferring it, but that's two possible reasons why there's an awful lot of MySQL deployments out there.

[0] https://codex.wordpress.org/Using_Alternative_Databases

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by ars on Wednesday January 12, 2022 @02:03PM (#29911369)

MySQL is much easier to administer and upgrade.

For example I have two versions of Postges running on my machine right now because Debian does not automatically upgrade between them - you have to export your data, and reimport it into the new version.

https://www.pontikis.net/blog/update-postgres-major-version-...

MySQL just works. There are issues with it, but they are not as major as people make them out to be. Sometimes people like "technical purity" over just get the job done.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by _moof on Wednesday January 12, 2022 @02:27PM (#29911640)

> MySQL just works

Right up until one of your users tries to use an emoji, apparently.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by astrange on Wednesday January 12, 2022 @09:02PM (#29915895)

MySQL doesn't have to know that a db is UTF8 for you to store UTF8 in it. You're not necessarily using its collation functions or anything.

My understanding is replication and setting up MySQL is still easier than Postgres; it definitely was 10 years ago, that's why it's part of LAMP. The data loss issues were fixed forever ago when it switched to InnoDB.

Google AdWords and Facebook both use(d) MySQL a lot and I assume they knew about Oracle and Postgres at the time they were built…

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by rrdharan on Wednesday January 12, 2022 @09:54PM (#29916258)

> Google AdWords and Facebook both use(d) MySQL a lot and I assume they knew about Oracle and Postgres at the time they were built…

Why would you assume that? Both of the companies were tiny and full of children when these decisions were made. And Oracle was expensive and a non-starter for explosive horizontal scale.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by astrange on Sunday January 16, 2022 @10:29PM (#29963035)

Well, because I remember 2005 and the Postgres people were just as into posting about how superior it was as they are now.

(Where they had a point because MySQL hadn't switched to InnoDB yet.)

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by outworlder on Wednesday January 12, 2022 @02:49PM (#29911897)

Keep in mind that that's a post from 2016. PG has made many improvements since then. Upgrading is a much easier job right now.

Also, it's strange to conflate PG with Debian issues.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by Spivak on Wednesday January 12, 2022 @07:18PM (#29914914)

I mean it's not really a Debian issue when Debian's design decisions were informed by the lack of automatic online upgrades at the time.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by Thaxll on Wednesday January 12, 2022 @06:11PM (#29914083)

User mgmt on PG is terrible, same for replication, connection pooling also sucks, InnoDB is faster overall than PG. Tooling is inferior to MySQl as well as clustering and upgrade process.

PG is great but its still has a lot of issues.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by kstrauser on Wednesday January 12, 2022 @12:29PM (#29909955)

Job security. I can’t think of any technical reasons.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by ars on Wednesday January 12, 2022 @02:04PM (#29911383)

Other way around - Postges will give you more job security, since it's rarer and takes more time and work to administer.

People use MySQL because it's easy, and they want to spend their effort in other places.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by kstrauser on Wednesday January 12, 2022 @02:46PM (#29911861)

That's like saying Python is rarer than JavaScript. Even if it's true, it's not actually rare at all.

In the last 6 years, I've spent approximately 2 hours administering PostgreSQL, and I'd be the one who had to do it.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by jiggawatts on Wednesday January 12, 2022 @03:05PM (#29912059)

It’s “easy” until it silently shreds data and gets your org hacked through truncation attacks.

Don’t confuse lazy with easy.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by MobiusHorizons on Thursday January 13, 2022 @01:22AM (#29917442)

I have been told that MySQL / MariaDB is significantly more scalable than Postgres, although I expect that opinion is based on old data. I don't have firsthand knowledge of this, so I can't comment further. Came to the comments to see if anyone knowledgeable would react to that point. (maybe they can reply here :) )

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by kstrauser on Thursday January 13, 2022 @03:46PM (#29926598)

Last I heard, it's the opposite: MySQL/MariaDB might be faster for single connections, but PostgreSQL can be much faster for heavy workloads. For instance, PostgreSQL added a feature to support sharing table scans between multiple connections. Suppose you have a million rows in a table "foo".

- Connection 1 executes "select * from foo". It begins at row 1 and starts a table scan.

- When the reader is at row 500,000, connection 2 executes "select * from foo". It starts returning results beginning at row 500,000, so both connections are sharing the output of the reader.

- When the reader gets to row 1,000,000, the first query is finished. It's seen all the rows. The reader starts back at row 1, and continues feeding results to the second query until it gets back to run 499,999. Then the second query is also finished.

Even though 2 queries were running, the DB backend was only doing the work of 1. With that setup, you could have 100 "select * from foo" queries running simultaneously without increasing the database load at all.

I don't know if MySQL supports that kind of thing now. In any case, that's an example of some of the incredible engineering PostgreSQL uses to be correct and fast.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by CRConrad on Friday January 21, 2022 @11:26AM (#30025780)

Even though 2 queries were running, the DB backend was only doing the work of 1.

Well, one and a half. Or the work of one query, but one and a half times.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by isotopp on Friday January 14, 2022 @01:49PM (#29938458)

If, in a customer facing database, you have to table scan, you have already lost.

For data warehouses this is a different story, but god help you if you are table scanning in OLTP context.

[ Parent | on HN ]