This is close to ridiculous.<p>I have to manage both types of DBMS.<p>Postgres never failed, the concepts are harder to grasp and it thus isn't easy to overcome every hurdle immediately.<p>MySQL on the otherhand failed in so many ways that I stopped counting.
What hit us the most:
* Exports that weren't importable, broken (fields larger in export than allowed?!?) -- or read: a database in a state that wasn't able to go into a backup == garbage<p>* Imports silently ignoring constraints (yeah, once you know all the restrictions, that's manageable, but what a horrible DBMS!)<p>* ...<p>We only keep using it for legacy projects were migrating away isn't worth it.
I manage Oracle, MySQL and, Postgresql (and even one SQLite, but "manage" doesn't quite describe the job).<p>Postgresql and MySQL are about the same complexity to manage: it's easy. Even compiling Postgresql is quick and trivial.<p>But Postgresql has a lot of features that make it the best database for an enterprise environment, especially FDW. Oracle has HS, but it is slow and not very reliable.<p>Overall, I'd say Postgresql and MySQL take hours of my time yearly. Oracle takes months of my time each year. SQLite doesn't take any time, but its use is limited.
This would be an interesting article to flesh out.
I.e is there evidence that MySQL is more reliable in those ways?<p>I always prefer reliability over features even though I’m a product engineer so if he’s right it’d be good to know.
Either way, I’m stuck with the MySQL that the infrastructure engineers at work have provided us with.
> Infrastructure engineers generally care most about [...] never, ever, losing data.<p>Does MySQL still silently truncate varchar columns when the inserted text is too long?