Why infrastructure engineers prefer MySQL (opens in new tab)

(mikecoutermarsh.com)

17 pointskpommerenke4y ago11 comments

11 comments

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.

forinti4y 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.

iRobbery4y ago

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

forinti4y ago

We only ever use MySQL if some software requires it.

tybit4y 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.

jpgvm4y 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.

tlhunter4y 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?

ncmncm4y 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.

forinti4y 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.

auspex4y ago

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

xdfgh11124y ago

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

j / k navigate · click thread line to collapse

11 comments

benjamir4y 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.

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

forinti4y 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.

iRobbery4y ago

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

forinti4y ago

We only ever use MySQL if some software requires it.

tybit4y ago

This would be an interesting article to flesh out. I.e is there evidence that MySQL is more reliable in those ways?

jpgvm4y 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.

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.

tlhunter4y 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?

ncmncm4y 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.

forinti4y 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.

auspex4y ago

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

xdfgh11124y ago

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

j / k navigate · click thread line to collapse