Hacker News Reader

Comment by bombcar | Hacker News Reader

This is the root of it all - for years and years MySQL was perfectly capable of doing the needful, but it shipped with default configurations that would do things like use "not_quite_really_UTF8" and "myisam_tables_please_no_acid".

If you knew enough to switch to innodb and "mysql_real_utf8_string" or whatever it was, you had a quite performant and stable system.

View on HN

There have also been numerous horror stories where people discovered (after the fact) that MySQL wasn't storing their data as given, but instead internally silently converting it to some other format/type and storing that.

People that directly experienced this very thing will probably chime in to give examples (etc). :)

Yep - ME! Happened to ME! Now some will blame bad development, should have caught it in the application code via testing, etc.

A 'true' DBMS will provide some guarantees and rather fail a transaction than do a 'best endeavours' job with it.

You hit the nail on the head, those were my top two complaints, but the rabbit hole goes deep.

It's not an exaggeration to say that trying to keep mysql from corrupting your data feels like a full-time job. Mysql in many ways, especially as used by massive social media companies early on was closer to a SQLish DSL for a non-transactional kv store than a "real" ACID database.

That's why "but it can do 70k rps" is just noise to someone. I don't care how fast it can lose my data.

I'm all for people needing to read the docs but man a database burns trust pretty fast when it's so easy to have it pretend to support transactions or pretend to support utf8.

Reply on news.ycombinator.com