7 ms·

As a big user of MySQL - moving off of it does seem like a good idea, if you can. The longer you wait, the harder it will be to flee

alfiedotwtf 2mo ago
Any reason besides trust me bro?
- zinodaur 2mo ago
  - 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
  - ksec 2mo ago
    >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 2mo ago
      Yep. In 2026 I’m still hearing that MySQL is terrible because of MyISAM
  - evanelias 2mo ago
    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.
    - alfiedotwtf 2mo ago
      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
    - zinodaur 2mo ago
      > 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 2mo ago
It's a large ecosystem with multiple server vendors (Oracle MySQL, MariaDB, Percona, VillageSQL) that are relatively easy to migrate between, compared to moving to a completely different DBMS ecosystem. Sometimes there are valid technical motivations to move away completely, but a nonsensical fear of a massively-used GPL database somehow becoming closed-source (with no surviving forks or continuity) is not one of them in my book!

alfiedotwtf 2mo ago

Any reason besides trust me bro?

zinodaur 2mo ago
- 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
- ksec 2mo ago
  >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 2mo ago
    Yep. In 2026 I’m still hearing that MySQL is terrible because of MyISAM
- evanelias 2mo ago
  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.
  - alfiedotwtf 2mo ago
    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
  - zinodaur 2mo ago
    > 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 2mo ago

It's a large ecosystem with multiple server vendors (Oracle MySQL, MariaDB, Percona, VillageSQL) that are relatively easy to migrate between, compared to moving to a completely different DBMS ecosystem. Sometimes there are valid technical motivations to move away completely, but a nonsensical fear of a massively-used GPL database somehow becoming closed-source (with no surviving forks or continuity) is not one of them in my book!