5 ms·

"Not as robust as MySQL"? Surely you're joking.

Propelloni 2y ago
It is hard to live down a reputation ;) MySQL was immortalized as the database in every LAMP stack. And just like PHP it improved considerably since then.
- p_l 2y ago
  Also for licensing reasons for a long time there was surviving contingent of MySQL 3.23 in LAMP hosting.
  - johannes1234321 2y ago
    While that change from LGPL to GPL affected only the client library (server always was GPL(+commercial)) and the MySQL company relatively quickly reacted with a FOSS exception to the GPL and by providing a reimplementation of the client library under PHP license (mysqlnd) to serve that market. (I joined MySQL shortly after that mess, before the Sun acquisition)
    - p_l 2y ago
      Random hosting providers that were major place for having your baby steps on LAMP stack didn't necessarily grok licensing much
      - johannes1234321 2y ago
        They also didn't like updating software - to likely that update to PHP or MySQL or something broke some bad script by a customer, who'd complain to the host.
sgarland 2y ago
They’re not wrong. If you’ve ever spent meaningful time administering both, you’ll know that Postgres takes far more hands-on work to keep it going. To be clear, I like both. Postgres has a lot more features, and is far more extensible. But there’s no getting around the fact that its MVCC implementation means that at scale, you have to worry about things that simply do not exist for MySQL: vacuuming, txid wraparound, etc.
- wbl 2y ago
  Yeah but you don't need to worry about your data existing. MySQL has been known to silently fail the one job of a DB.
  - SavageBeast 2y ago
    I recall this being the case A LOOOONG time ago but I haven't heard of, read about, been warned to look out for or personally seen such a thing in forever. Have you? * I'm running a lot of MySQL stuff and such a topic might be of interest to me
    - o11c 2y ago
      From what I can tell, MySQL is supposed to be safe since 2018 if you have no data from before 2010. The fact that you still can't use DDL in transactions makes life exceedingly painful, but it's technically safe if you write your migration code carefully enough.
      - The_Colonel 2y ago
        Lack of transactional DDL is certainly painful, but not unique for MySQL. Oracle doesn't support it either.
        justinclift 2y ago
        Both databases are owned by the same company. Wonder if it's something inherent to the company which has keep that limitation going?
erik_seaberg 2y ago
Early MySQL versions made egregious design choices like quietly ignoring missing foreign keys and enum typos, truncating long strings, and randomly choosing rows from groups. https://web.archive.org/web/20230922210124/https://grimoire.ca/mysql/choose-something-else/#data-processing https://web.archive.org/web/20230922210124/https://grimoire....
- sgarland 2y ago
  Yeah, it was bad. What kills me is SQLite has its own absurd set of gotchas [0] yet is seen as amazing and wonderful by devs. PKs can have NULLs? Sure! Strings can have \0 in the middle of them? Why not? FKs aren’t enforced by default? Yeah, who needs referential integrity, anyway? My only conclusion is that the majority of devs don’t actually read documentation, and rely purely on the last blog post they read to influence their infrastructure decisions. [0]: https://www.sqlite.org/quirks.html https://www.sqlite.org/quirks.html
  - hu3 2y ago
    Understanding and memorizing shortcomings and quirks takes time and effort. Most devs just go with whatever the influencer du jour says is good. "Nobody ever got fired for choosing insert_currently_hyped_tech_here"
slotrans 2y ago
It is funny reading the replies here. I am a database specialist and have worn the DBA had for many years. I have run MySQL and Postgres in production, both self-hosted and using managed services. Postgres wins on every single dimension that matters, every time. Yes MySQL is easier to setup for non-experts. That counts for nothing. If you are sticking up for MySQL in this thread... I just don't even know, man.

It is hard to live down a reputation ;) MySQL was immortalized as the database in every LAMP stack. And just like PHP it improved considerably since then.

p_l 2y ago
Also for licensing reasons for a long time there was surviving contingent of MySQL 3.23 in LAMP hosting.
- johannes1234321 2y ago
  While that change from LGPL to GPL affected only the client library (server always was GPL(+commercial)) and the MySQL company relatively quickly reacted with a FOSS exception to the GPL and by providing a reimplementation of the client library under PHP license (mysqlnd) to serve that market. (I joined MySQL shortly after that mess, before the Sun acquisition)
  - p_l 2y ago
    Random hosting providers that were major place for having your baby steps on LAMP stack didn't necessarily grok licensing much
    - johannes1234321 2y ago
      They also didn't like updating software - to likely that update to PHP or MySQL or something broke some bad script by a customer, who'd complain to the host.

sgarland 2y ago

They’re not wrong. If you’ve ever spent meaningful time administering both, you’ll know that Postgres takes far more hands-on work to keep it going. To be clear, I like both. Postgres has a lot more features, and is far more extensible. But there’s no getting around the fact that its MVCC implementation means that at scale, you have to worry about things that simply do not exist for MySQL: vacuuming, txid wraparound, etc.

wbl 2y ago
Yeah but you don't need to worry about your data existing. MySQL has been known to silently fail the one job of a DB.
- SavageBeast 2y ago
  I recall this being the case A LOOOONG time ago but I haven't heard of, read about, been warned to look out for or personally seen such a thing in forever. Have you? * I'm running a lot of MySQL stuff and such a topic might be of interest to me
  - o11c 2y ago
    From what I can tell, MySQL is supposed to be safe since 2018 if you have no data from before 2010. The fact that you still can't use DDL in transactions makes life exceedingly painful, but it's technically safe if you write your migration code carefully enough.
    - The_Colonel 2y ago
      Lack of transactional DDL is certainly painful, but not unique for MySQL. Oracle doesn't support it either.
      - justinclift 2y ago
        Both databases are owned by the same company. Wonder if it's something inherent to the company which has keep that limitation going?

erik_seaberg 2y ago

Early MySQL versions made egregious design choices like quietly ignoring missing foreign keys and enum typos, truncating long strings, and randomly choosing rows from groups. https://web.archive.org/web/20230922210124/https://grimoire.ca/mysql/choose-something-else/#data-processing https://web.archive.org/web/20230922210124/https://grimoire....

sgarland 2y ago
Yeah, it was bad. What kills me is SQLite has its own absurd set of gotchas [0] yet is seen as amazing and wonderful by devs. PKs can have NULLs? Sure! Strings can have \0 in the middle of them? Why not? FKs aren’t enforced by default? Yeah, who needs referential integrity, anyway? My only conclusion is that the majority of devs don’t actually read documentation, and rely purely on the last blog post they read to influence their infrastructure decisions. [0]: https://www.sqlite.org/quirks.html https://www.sqlite.org/quirks.html
- hu3 2y ago
  Understanding and memorizing shortcomings and quirks takes time and effort. Most devs just go with whatever the influencer du jour says is good. "Nobody ever got fired for choosing insert_currently_hyped_tech_here"

slotrans 2y ago

It is funny reading the replies here. I am a database specialist and have worn the DBA had for many years. I have run MySQL and Postgres in production, both self-hosted and using managed services. Postgres wins on every single dimension that matters, every time. Yes MySQL is easier to setup for non-experts. That counts for nothing. If you are sticking up for MySQL in this thread... I just don't even know, man.