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