Why infrastructure engineers prefer MySQL(mikecoutermarsh.com)
mikecoutermarsh.com
Why infrastructure engineers prefer MySQL
https://mikecoutermarsh.com/why-infrastructure-engineers-prefer-mysql/
5 comments
I manage Oracle, MySQL and, Postgresql (and even one SQLite, but "manage" doesn't quite describe the job).
Postgresql and MySQL are about the same complexity to manage: it's easy. Even compiling Postgresql is quick and trivial.
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.
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.
Postgresql and MySQL are about the same complexity to manage: it's easy. Even compiling Postgresql is quick and trivial.
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.
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?
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.
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.
It's not more reliable on those dimensions but it is "easier". For most cases you can enable statement based replication in MySQL and put it into semi-sync mode and it will mostly do what you want.
PostgreSQL on the other hand is less of a fully finished database w.r.t replication and more like a set of incredibly powerful tools that let you build the scale out, partitioned, replicated, CDC friendly/etc database cluster of your dreams. You can mix and match nodes setup with physical replication vs logical replication, you can use partitioning and table inheritance to increase scalability and hide the fact the database is actually distributed across many nodes/clusters from your application, etc.
I think there is probably some lag/delta here where PostgreSQL doesn't have an easy enough/simple enough story for basic replication modes outside of basic physical replication.
PostgreSQL on the other hand is less of a fully finished database w.r.t replication and more like a set of incredibly powerful tools that let you build the scale out, partitioned, replicated, CDC friendly/etc database cluster of your dreams. You can mix and match nodes setup with physical replication vs logical replication, you can use partitioning and table inheritance to increase scalability and hide the fact the database is actually distributed across many nodes/clusters from your application, etc.
I think there is probably some lag/delta here where PostgreSQL doesn't have an easy enough/simple enough story for basic replication modes outside of basic physical replication.
> Infrastructure engineers generally care most about [...] never, ever, losing data.
Does MySQL still silently truncate varchar columns when the inserted text is too long?
Does MySQL still silently truncate varchar columns when the inserted text is too long?
See, that doesn't affect infrastructure engineers at all. It's "working as designed", howsoever bad the design is, so they get no calls about it.
Long time ago I was debugging an application and realised MySQL would let me put anything in a column that was supposed to be numeric. It didn't even check the length constraint.
No, it throws an error letting you the the text is too long for the field
Not for a very long time, look up strict mode.
I have to manage both types of DBMS.
Postgres never failed, the concepts are harder to grasp and it thus isn't easy to overcome every hurdle immediately.
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
* Imports silently ignoring constraints (yeah, once you know all the restrictions, that's manageable, but what a horrible DBMS!)
* ...
We only keep using it for legacy projects were migrating away isn't worth it.