Live data from Hacker News

Ask HN: It's 2023, how do you choose between MySQL and Postgres?

news.ycombinator.com

131–140 of 366 posts

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#132
post #109

Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…

samesies

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#134
post #36

There is almost no good reason to choose MySQL over PostgreSQL for any operational reason, I did a deep dive many moons ago (before major improvements in performance to postgres) and people were saying that MySQL was faster. I found that not to be true and the differences have only gained even more favour towards postgres. also, I assume you mean MariaDB as MySQL is owned by Oracle and I would greatly implore anyone…

> avoid Oracle as if it has herpes herpes isn't that bad. most people will get it in their lifetime. 1 in 6 people have hsv-2, the less common variant. trying to avoid herpes is like trying to avoid chickenpox (although herpes isn't nearly as harmful as chickenpox). you should avoid Oracle like it's a blood pathogen.

hello, fellow person with herpes! (I assume)

The worst part about having it is having to talk about having it. It's really not bad as a condition separate from societal concern.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#136
post #83

Postgres. Fast, full-featured, rock-solid, and a great community. I think many of us can’t be bothered to go over (again) the issues we’ve had with MySQL in the past. The last straw for me was about ten years ago, when I caught MySQL merrily making up nonsense results for a query I’d issued that accidentally didn’t make any sense. Very likely this particular issue, and others like it, have been fixed in the meantime.…

Having used postgres for the past decade, I tried MySQL for a side project to see whats changed with it. The sad answer is that it feels like nothing has changed - Oracle seems to have let what used to be a core technology of the industry languish. I'm sure there are use cases where MySQL will be the better choice over postgres, but the future for the stack looks bleak.

Creating a series of connections very quickly is cheaper in MySQL and MariaDB than in PostgreSQL. Typically, a connection poller is used before PostgreSQL to support connection scalability.

I'm not sure if there has been a recent breakthrough that has changed that. I think that still applies today. Correct me if I'm wrong.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#137

Earlier quoted context omitted.

This is the correct answer. Whichever one you start out with, you will be annoyed if you switch to the other one 5 years later. I started out with mysql, and when I started working on a postgres project, I was shocked at some of the ways it was lacking (how am I supposed to store email addresses in a database without collations?). But when postgres folks grouse about stuff in mysql, I'm usually nodding along and sayi…

> when I started working on a postgres project, I was shocked at some of the ways it was lacking (how am I supposed to store email addresses in a database without collations?) How long ago was this? :)

3 years ago. From this comment thread https://news.ycombinator.com/item?id=35908169 I infer that Postgres still doesn't support collations.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#139

Am I the only one who thinks postgresql’s timestamp and timestamptz types are incredibly stupid? I just want to either save a local date and time, or an utc timestamp. Postgresql’s timestamp(tz) types do neither and both at the same time.

I've avoided `timestamp` and haven't needed localized times stored in the DB, but in what way is `timestamptz` not exactly the utc timestamp you expect?
Post reply on HN