[zinodaur]

- Its query planner is ancient and broken - it comes up with very bad plans. Every time we rely on it, we regret it eventually

- you have to use locks to prevent mangled write transactions, instead of the db handling it. Jepsen report is scathing

- its pretty hard to set it up in semi-sync replication mode, a.k.a. "only return from a transaction commit when the transaction is present on at least one other replica". Once you've set it up, you have to deal with insane things like transactions being visible on replicas before leaders, or even worse transactions visible on replicas briefly but never visible on leaders or other replicas

- every knob and feature contains subtle bugs, sometimes ones as scary as index corruption, that you only discover after it has caused you pain

I don't know why you would choose it unless you were already running it

[evanelias]

The query planners have diverged between MySQL and MariaDB; which one are you talking about? Both have received improvements in recent years, so the specific version is relevant as well. And at least both systems have supported index hints for decades (unlike another popular database that only very recently acknowledged their necessity in large production workloads...)

The locking anomalies are a well-known and well-documented side effect of InnoDB REPEATABLE READ differing from the standard in certain pathological cases. The real-world relevance is minor, especially since companies using external write-through caches are already making much worse inherent trade-offs in that area. Regardless, MariaDB fixed it, while providing an option to revert to the old behavior for MySQL compatibility. And fwiw this only comes up because MySQL/Maria defaults to REPEATABLE READ; yet meanwhile the overwhelming majority of Postgres users are totally fine with the much weaker guarantees of READ COMMITTED, because that's their default isolation level.

Semi-sync has some odd behaviors indeed; there are conceptual trade-offs that must be made if you want synchronous-like replication without the full performance penalty! Do you have some novel academic solution for this that you can propose?

Your last bullet is lacking in details so I cannot comment.

[zinodaur]

> The query planners have diverged between MySQL and MariaDB; which one are you talking about? Both have received improvements in recent years, so the specific version is relevant as well. And at least both systems have supported index hints

MySQL - we use the index hints 100% of the time because the query planner (still) doesn't work

> The real-world relevance is minor, especially since companies using external write-through caches are already making much worse inherent trade-offs in that area

I disagree - everyone knows that the cache value can be stale, and to be wary of it if your use case requires correctness. In my experience people tend to expect correct, up to date data from their database - which is why they usually have to opt in to read-replicas

> Do you have some novel academic solution for this that you can propose?

MySQL doesn't support synchronous replication - so semi sync is the next best thing. Then you wrestle with it to make it not crazy (e.g. - only count a tx as acked if it was acked by a replica that has all the other txes). Its not rocket science - maybe the big fanfare about synchronous replication made sense when a disk write was incredibly slow, but adding 2 ms of network latency and 5ms to persist it on another machine in order to not lose user data seems like a pretty straightforward choice to me. And if write performance matters that much to you - you shouldn't be using a dinosaur like MySQL anyways

[evanelias]

> MySQL

You still haven't indicated what version. For example there's a substantial join planner improvement in the latest LTS (MySQL 9.7). And in any case the original thread was about MariaDB, not MySQL.

> I disagree

OK, but again MariaDB literally solved the anomaly in the Jepsen report. So if this particular problem is so important to your use-case, why are you still using MySQL?

> In my experience people tend to expect correct, up to date data from their database

Then why do the vast majority of Postgres users stay with their default READ COMMITTED isolation, which provides weaker guarantees than MySQL's supposedly-problematic version of REPEATABLE READ?

> MySQL doesn't support synchronous replication - so semi sync is the next best thing

Despite not being fully synchronous, MySQL Group Replication has been available for years and is more synchronous than traditional semi-sync was. It solves the semi-sync problems you are describing. Ditto with Galera in MariaDB. They're just not a great fit for extremely high-write-volume OLTP, since they make the latency tradeoff you're describing.

> if write performance matters that much to you - you shouldn't be using a dinosaur like MySQL anyways

Properly-tuned InnoDB provides excellent write performance on par with competitors. Ditto for MyRocks. This is why many of the largest tech companies are still using MySQL as their primary database.

[alfiedotwtf]

Citing semi-sync thinking everything would be automatic was a weird con against MySQL. I’m now trying to think how the hell other databases magically solve this without needing to handle edge cases

[ksec]

>I don't know why you would choose it

Vitess. Also I often wonder if these system are on latest mySQL? I have read plenty of mySQL opinions that still based their experience during 5.x era.

[alfiedotwtf]

Yep. In 2026 I’m still hearing that MySQL is terrible because of MyISAM