7 ms·

> Generally friends don't let friends use Mysql What drives this sentiment?

by wbercx 2y ago

WJW 2y ago
MySQL used to have some rather dodgy defaults way back and some people haven't touched it for decades and assume it's still like that. Also it got acquired by Oracle at some point and many people just hate Oracle. Finally it is now cool to love Postgres more, or sqlite. MySQL is fine, boring tech that powers a great many companies. There's nothing wrong with choosing it for a new venture, but there's also nothing wrong with another choice. Which RDBMS you use won't be the deciding factor in your success these days.
- cies 2y ago
  We're using MySQL and collectively wish we were on Postgres. It's waaaay more quirky in our experience. Also: Oracle hate is not unwarranted, even in this day-and-age. > There's nothing wrong with choosing it for a new venture I'd advise anyone in that position not to choose MySQL. Go with Postgres unless you have a good reason not to.
  - gnz11 2y ago
    MySQL is just fine for most cases. Postgresql has its warts too. Restoring a MySQL db is far simpler and smoother compared to Postgresql IMO for example.
    - WJW 2y ago
      My "favorite" postgres wart comes from a thing it should be good at: transactional ALTER TABLE. This works fabulously until you need to migrate a big (few hundred million rows, say) table in a way that requires a table rewrite. Vanilla Postgres will just lock up the table until it's done, so you need some online schema migration tool. The fun thing is MySQL will also require schema migration tooling, but since their native migrations are so bad the tooling around it has evolved to be much better. Things like pt-osc and gh-ost will kick the butt of anything Postgres has, let alone when you pull out the big boy tools with Vitess. Don't get me wrong, most databases will never need such tooling whether they're Postgres or MySQL. But still I find it interesting that (for the migration story at least) at small scale they're equal, then at medium scale Postgres wins out and at larger scales MySQL starts to win again.
      - cies 2y ago
        > at small scale they're equal, then at medium scale Postgres wins out and at larger scales MySQL starts to win again. Nice insight! I'd say because most apps wont reach mega scale, that on the small scale Postgres should win. Also having to deal with less quirks is really nice on small scale too!
  - wbercx 2y ago
    What sort of quirks have you run into? I find myself having to STRAIGHT_JOIN more often than I would like because it simply won’t generate sensible execution plans sometimes.
    - cies 2y ago
      so many. just some of the top of my mind: * sub-query needs to be wrapped in a sub-query * we had an issue recently (dont have the link at hand) where mysql team closed the bug as fixed but only documented it as a "know issue". we had to split up one query in 5 queries to fix this * ask Lucas Eder what is a better db, he has intimate experience with all of 'm Here are some we also run into: https://www.codementor.io/@goetas/why-i-prefer-postgresql-to-mysql-hikp0wbu6 https://www.codementor.io/@goetas/why-i-prefer-postgresql-to...
hu3 2y ago
In 2025? Often a tribalistic ignorance of holding outdated preconceptions against MySQL. A quick search hints me that there is still more ultra-large MySQL setups than there are PostgreSQL. By a large margin it seems. Between easier upgrades/HA, thread connection model, Vitess and engines like MyRocks, it's hard to beat for many use cases.
- guitarbill 2y ago
  Time and survivorship bias can explain the ultra-large MySQL usage, given it used to be the popular choice.
asddubs 2y ago
same as php hate, mysql had some questionable design decisions and legacy hacks, which are mostly not that relevant today except for causing some warts on the interface (like e.g. utf8mb4, mysql_real_escape_string)
- cies 2y ago
  Very similar to PHP indeed! PHP is also something I'd not advise anyone to use on a greenfield app unless you have really good reasons for doing so. There are much better --also very conservative-- stacks available for free (and no, those are not JS based). For instance: Kotlin, http4k, JTE/KTE (or kotlinx.html), SQLDelight, Postgress.
  - gnz11 2y ago
    You say you "advise" and don't give any specifics. So why Kotlin over the myriad of other options? Picking a LAMP stack is picking a stack that is battle tested — nothing wrong with that for new projects.
    - cies 2y ago
      Kotlin is basically Java 2.0. Kotlin has really great developer ergonomics and a huuuge ecosystem of Java libs you can easily use since you are on top of the JVM which (a much better tech than PHP). Kotlin being quite high-level fits well with webdev (I'd only use Rust for super perf critical web dev for instance). Kotlin is OO-code (easy for new devs) with lots of FP goodness (as that's where the party's at). Big shops with big legacy PHP code bases all move away from it. LAMP = Linux (sure), Apache (no-way, use NGINX or in app web server instead), MySQL (sorry, Postgres won) and PHP/Perl (these langs are going the way of the Dodo). So LAMP is a bad choice nowadays. I'd say it has been since Ruby on Rails 1.0.
  - DeathArrow 2y ago
    Golang and C# would be fine picks, too.
    - 2y ago
cess11 2y ago
MySQL 5 had bad defaults. Some would probably argue that hooking into sudo rather than a dedicated databaser user amounts to one. MySQL is also perceived by some to be a software for amateurs. Unless you need the kind of sophisticated extensions Postgres supports MySQL is likely to be a good fit. The query planner is straightforward, performance tuning slightly more predictable and easy compared to Postgres.
- kaptainscarlet 2y ago
  MySQL is more user friendly. Examples are, autoincrement vs postgres sequences, case sensitivity, users ans databases are straightforward on mysql vs roles, dbs and schemas on postgres. Replications are also easy to setup on mysql.
- evanelias 2y ago
  > Some would probably argue that hooking into sudo rather than a dedicated databaser user amounts to one What are you referring to here?
  - cess11 2y ago
    Postgres is administered through a postgres user.
    - evanelias 2y ago
      Sure, and MySQL is administered through a mysql user. When people talk about bad defaults in old MySQL, they're typically referring to lack of strict sql_mode by default prior to MySQL 5.7 (2015). They're not talking about OS users. I've been using MySQL for 22 years and your comment about sudo bears no resemblance to anything I've ever experienced.
      - cess11 2y ago
        Not in my experience. It might run as a mysql user but I can't remember having su:d to it. Maybe you can give some examples of administration that require you to? Collations and charsets and the DB engine and other stuff wasn't particularly good either, but I can't be arsed to figure out specifically when so I glossed over the details. I don't think it matters. 8 is what, a decade old or so?
mianos 2y ago
Things that are missing in most other proper databases, like transactional DDL. If you don't mind not having them, Mysql is fine. It's probably better than Postgres for mostly read databases, which is most uses. There was a time when Mysql was by far the most used but over the years it's growth has been fairly slow and Postgres has kept growing in use, mainly due to functionality and integrity. People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources). If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.
- evanelias 2y ago
  > People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. You seem to be under the impression that MySQL just "fails" on random read queries? That is nonsense. In reality Facebook's db fleet is a massive sharded system, and sometimes shards are temporarily offline due to hardware failure on the shard's primary/writer node, but it's quite brief in the vast majority of cases. When you have such a massive number of servers, hardware failures happen many times a day. Due to caching and other services it's also a multi-leveled data access stack, so a page load could fail due to some non-MySQL component having problems as well. Or a network issue, etc. It's not magically MySQL's fault every time something goes wrong at Facebook. Meta uses MySQL for a variety of mission-critical use-cases, including financial ones. Every single committed MySQL write is replicated before success is returned to the calling code, nothing is lost or thrown away. > Things that are missing in most other proper databases, like transactional DDL [...] > some commercial thing like SQLServer or Oracle, where integritry is more highly important. And yet Oracle DBMS does not have transactional DDL either, so why aren't you equally critical of it here?
  - mianos 2y ago
    Oracle can not group DDL changes in a transaction, but if an alter table results in an integrity violation the whole thing is rolled back, unlike mysql, that stops where the integrity violation occurs. Maybe Oracle is not as good as Postgres but it's workable. That's if you want to be shafted on licenses anyway.

> Generally friends don't let friends use Mysql What drives this sentiment?

by wbercx 2y ago

> Generally friends don't let friends use Mysql What drives this sentiment?

WJW 2y ago

MySQL used to have some rather dodgy defaults way back and some people haven't touched it for decades and assume it's still like that. Also it got acquired by Oracle at some point and many people just hate Oracle. Finally it is now cool to love Postgres more, or sqlite. MySQL is fine, boring tech that powers a great many companies. There's nothing wrong with choosing it for a new venture, but there's also nothing wrong with another choice. Which RDBMS you use won't be the deciding factor in your success these days.

cies 2y ago
We're using MySQL and collectively wish we were on Postgres. It's waaaay more quirky in our experience. Also: Oracle hate is not unwarranted, even in this day-and-age. > There's nothing wrong with choosing it for a new venture I'd advise anyone in that position not to choose MySQL. Go with Postgres unless you have a good reason not to.
- gnz11 2y ago
  MySQL is just fine for most cases. Postgresql has its warts too. Restoring a MySQL db is far simpler and smoother compared to Postgresql IMO for example.
  - WJW 2y ago
    My "favorite" postgres wart comes from a thing it should be good at: transactional ALTER TABLE. This works fabulously until you need to migrate a big (few hundred million rows, say) table in a way that requires a table rewrite. Vanilla Postgres will just lock up the table until it's done, so you need some online schema migration tool. The fun thing is MySQL will also require schema migration tooling, but since their native migrations are so bad the tooling around it has evolved to be much better. Things like pt-osc and gh-ost will kick the butt of anything Postgres has, let alone when you pull out the big boy tools with Vitess. Don't get me wrong, most databases will never need such tooling whether they're Postgres or MySQL. But still I find it interesting that (for the migration story at least) at small scale they're equal, then at medium scale Postgres wins out and at larger scales MySQL starts to win again.
    - cies 2y ago
      > at small scale they're equal, then at medium scale Postgres wins out and at larger scales MySQL starts to win again. Nice insight! I'd say because most apps wont reach mega scale, that on the small scale Postgres should win. Also having to deal with less quirks is really nice on small scale too!
- wbercx 2y ago
  What sort of quirks have you run into? I find myself having to STRAIGHT_JOIN more often than I would like because it simply won’t generate sensible execution plans sometimes.
  - cies 2y ago
    so many. just some of the top of my mind: * sub-query needs to be wrapped in a sub-query * we had an issue recently (dont have the link at hand) where mysql team closed the bug as fixed but only documented it as a "know issue". we had to split up one query in 5 queries to fix this * ask Lucas Eder what is a better db, he has intimate experience with all of 'm Here are some we also run into: https://www.codementor.io/@goetas/why-i-prefer-postgresql-to-mysql-hikp0wbu6 https://www.codementor.io/@goetas/why-i-prefer-postgresql-to...

hu3 2y ago

In 2025? Often a tribalistic ignorance of holding outdated preconceptions against MySQL. A quick search hints me that there is still more ultra-large MySQL setups than there are PostgreSQL. By a large margin it seems. Between easier upgrades/HA, thread connection model, Vitess and engines like MyRocks, it's hard to beat for many use cases.

guitarbill 2y ago
Time and survivorship bias can explain the ultra-large MySQL usage, given it used to be the popular choice.

asddubs 2y ago

same as php hate, mysql had some questionable design decisions and legacy hacks, which are mostly not that relevant today except for causing some warts on the interface (like e.g. utf8mb4, mysql_real_escape_string)

cies 2y ago
Very similar to PHP indeed! PHP is also something I'd not advise anyone to use on a greenfield app unless you have really good reasons for doing so. There are much better --also very conservative-- stacks available for free (and no, those are not JS based). For instance: Kotlin, http4k, JTE/KTE (or kotlinx.html), SQLDelight, Postgress.
- gnz11 2y ago
  You say you "advise" and don't give any specifics. So why Kotlin over the myriad of other options? Picking a LAMP stack is picking a stack that is battle tested — nothing wrong with that for new projects.
  - cies 2y ago
    Kotlin is basically Java 2.0. Kotlin has really great developer ergonomics and a huuuge ecosystem of Java libs you can easily use since you are on top of the JVM which (a much better tech than PHP). Kotlin being quite high-level fits well with webdev (I'd only use Rust for super perf critical web dev for instance). Kotlin is OO-code (easy for new devs) with lots of FP goodness (as that's where the party's at). Big shops with big legacy PHP code bases all move away from it. LAMP = Linux (sure), Apache (no-way, use NGINX or in app web server instead), MySQL (sorry, Postgres won) and PHP/Perl (these langs are going the way of the Dodo). So LAMP is a bad choice nowadays. I'd say it has been since Ruby on Rails 1.0.
- DeathArrow 2y ago
  Golang and C# would be fine picks, too.
  - 2y ago

cess11 2y ago

MySQL 5 had bad defaults. Some would probably argue that hooking into sudo rather than a dedicated databaser user amounts to one. MySQL is also perceived by some to be a software for amateurs. Unless you need the kind of sophisticated extensions Postgres supports MySQL is likely to be a good fit. The query planner is straightforward, performance tuning slightly more predictable and easy compared to Postgres.

kaptainscarlet 2y ago
MySQL is more user friendly. Examples are, autoincrement vs postgres sequences, case sensitivity, users ans databases are straightforward on mysql vs roles, dbs and schemas on postgres. Replications are also easy to setup on mysql.
evanelias 2y ago
> Some would probably argue that hooking into sudo rather than a dedicated databaser user amounts to one What are you referring to here?
- cess11 2y ago
  Postgres is administered through a postgres user.
  - evanelias 2y ago
    Sure, and MySQL is administered through a mysql user. When people talk about bad defaults in old MySQL, they're typically referring to lack of strict sql_mode by default prior to MySQL 5.7 (2015). They're not talking about OS users. I've been using MySQL for 22 years and your comment about sudo bears no resemblance to anything I've ever experienced.
    - cess11 2y ago
      Not in my experience. It might run as a mysql user but I can't remember having su:d to it. Maybe you can give some examples of administration that require you to? Collations and charsets and the DB engine and other stuff wasn't particularly good either, but I can't be arsed to figure out specifically when so I glossed over the details. I don't think it matters. 8 is what, a decade old or so?

mianos 2y ago

Things that are missing in most other proper databases, like transactional DDL. If you don't mind not having them, Mysql is fine. It's probably better than Postgres for mostly read databases, which is most uses. There was a time when Mysql was by far the most used but over the years it's growth has been fairly slow and Postgres has kept growing in use, mainly due to functionality and integrity. People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources). If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.

evanelias 2y ago
> People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. You seem to be under the impression that MySQL just "fails" on random read queries? That is nonsense. In reality Facebook's db fleet is a massive sharded system, and sometimes shards are temporarily offline due to hardware failure on the shard's primary/writer node, but it's quite brief in the vast majority of cases. When you have such a massive number of servers, hardware failures happen many times a day. Due to caching and other services it's also a multi-leveled data access stack, so a page load could fail due to some non-MySQL component having problems as well. Or a network issue, etc. It's not magically MySQL's fault every time something goes wrong at Facebook. Meta uses MySQL for a variety of mission-critical use-cases, including financial ones. Every single committed MySQL write is replicated before success is returned to the calling code, nothing is lost or thrown away. > Things that are missing in most other proper databases, like transactional DDL [...] > some commercial thing like SQLServer or Oracle, where integritry is more highly important. And yet Oracle DBMS does not have transactional DDL either, so why aren't you equally critical of it here?
- mianos 2y ago
  Oracle can not group DDL changes in a transaction, but if an alter table results in an integrity violation the whole thing is rolled back, unlike mysql, that stops where the integrity violation occurs. Maybe Oracle is not as good as Postgres but it's workable. That's if you want to be shafted on licenses anyway.