Hacker News Reader

Comment by WJW | Hacker News Reader

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.

View on HN

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.

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.

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 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.

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.

> 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!

Reply on news.ycombinator.com