Why infrastructure engineers prefer MySQL

Why infrastructure engineers prefer MySQL(mikecoutermarsh.com)

17 points by kpommerenke 4 years ago | 11 comments

benjamir 4 years ago |

This is close to ridiculous.

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.

forinti 4 years ago |

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.

iRobbery 4 years ago | |

I fully agree, but i slightly prefer postgresql over mysql due to their licensing

forinti 4 years ago | | |

We only ever use MySQL if some software requires it.

tybit 4 years ago |

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.

jpgvm 4 years ago | |

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.

tlhunter 4 years ago |

> Infrastructure engineers generally care most about [...] never, ever, losing data.

Does MySQL still silently truncate varchar columns when the inserted text is too long?

ncmncm 4 years ago | |

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.

forinti 4 years ago | |

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.

auspex 4 years ago | |

No, it throws an error letting you the the text is too long for the field

xdfgh1112 4 years ago | |

Not for a very long time, look up strict mode.