In-memory capability, hiring pool of MySQL/MariaDB developers tends to be larger/wider, Galera cluster (M-M functionality), if the queries trend towards simplicity then MySQL/MariaDB tends to be more performant, Postgres can have issues with write amplification, etc.
Uber (I know, I know) switched to MySQL, here are some reasons why:
I never understood which table caused these issues at Uber. They use an example with birthday changes for users. That's no real world example. Apparently issues were caused by a small table updated 500+ times a second and used in a lot of joins. That could be the driver table but why would they update it so much? Personal information rarely changes and live information about the driver (trip status, position, online/offline) should be stored separate from that? And you wouldn't need transactions around those updates?
Did they ever clarify what data actually caused the issues?
please don't use uber as an example.
they made just so many mistakes with postgresql (mistakes that would probably blow up a ton of databases including mysql)
not sure if galera cluster is a good thing.. we've started out with galera and it was a pain. we now run on postgres, but even if we would've stayed with mysql we wouldn't use galera anymore. network split was a pita, even if you had major quorum.
I'm aware of the memory capabilities of mysql in general, but the insinuation was that mysql had more capabilities of in-memory processing than postgres - I dont see anything in those links that are things that postgres cant do - although they may be implemented differently.
The honest answer is that you can get the desired result with Postgres, even if it might require a custom foreign data wrapper implementation. Carpenters pick their favorite saws, and they like MySQL.
To be fair, uber did get burned by a Postgres replication failure- but they also had a NOC team promote 3 bad replicas to primary before stepping back to reconsider their approach. Carpenters do hate losing their fingers in circular saws.
MySQL is faster. There are people that will argue against it but they probably don't understand how the vacuum works. Also if you only read HN yeah you're bias on Postgres vs MySQL. On the end Postgres is "better" but MySQL is already pretty good, it's not like you're comparing a good product to a bad one, both of them are good.
That question could be asked in a reversed fashion too. PostgreSQL is the favorite database here on HN (I prefer it too) but for a generic company out there MySQL/PostgreSQL are interchangeable. Won't really matter which one you choose and I think it's easier to hire people with MySQL experience.
I actually had databases class which used MySQL for exercises and essentially it was like this:
* you can configure triggers for a table, but you can't use them in MySQL unless you make sure the table is InnoDB (this was a while ago before defaults changed)
* MySQL doesn't support aborting INSERT/UPDATE/DELETE from trigger, but you can emulate it by throwing an exception
* a table can have a CHECK constraint, but you can't use it because it is not available in MySQL
Makes one wonder MySQL was picked for that class. I get that it was because it was very popular at the time, but it felt like a toy compared to a functionality that any other database had.
I'm interested in what people's experiences here are. I spent the entire of my degree deep in Oracle, persistently being warned a database without object-relational queries were absolutely never used in the real world (how ironic).
