Hacker News Reader

> And while they've recently announced more of this stuff will move to FOSS soon, at the same time their response rate to new bug reports has become worse than ever before, which is deeply worrying.

A huge chunk[1] of the MySQL developers were laid off (and also large amounts of QA etc.), so it's not surpising at all that they are struggling to keep the lights on. There are talks about an external group trying to form to take more ownership, but so far, your best bets are MariaDB or Postgres, depending on whether you think MySQL 5.1 was the epitome of relational databases or not.

[1] From what I gather, about 75%. In the first wave.

> Many workloads don't need something like Galera [etc...]

This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure. So many open-core models rely on this falsehood to rationalize their decisions. It should be possible to run large-scale important Internet things on Open Source code, too, for a variety of reasons.

> This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure.

How so? I don't understand your comment at all. A huge chunk of the world's economy runs on async replication in FOSS MySQL/MariaDB, my whole point was that you literally don't need Galera to do that.

> such as vector indexes and JS stored procedures

So, the stuff that basically appeals to people chasing the AI dragon, and has zero practical use for 99.999% of developers making real products?

> I wish I was joking!

I wish I could care even a little bit about such minutiae.

If you've ever had to work with nontrivial procs in MySQL/MariaDB, it's immediately clear how the status quo is deficient there, and why e.g. Postgres's multi-language support is so much better in comparison.

And how is it "minutiae" to be able to figure out "is my database version actually supported"? This is the fourth versioning scheme they've used in less than a decade, that's a bit nuts I think.

I would happily write stored procs using the current language support for a decade without pay, before I'd subject myself to putting javascript in a fucking database engine.

> And how is it "minutiae" to be able to figure out "is my database version actually supported"?

Remembering "8.4", "9.7" and ".4" just doesn't seem like a particularly big deal to me. The number* has only changed 3 times in the last 10 years.

I don't like JS either, but lots of people do. And if you're expanding a DB beyond SQL-only, JS is an obvious first choice before adding further languages from there. (The MySQL feature is called "Multilingual Engine Component" and not "JavaScript Engine Component".)

As for the versioning, it's a nightmare for third party vendors like me, because it will absolutely increase the number of companies who are unintentionally running unsupported non-LTS "innovation" releases because they can't keep all these versioning changes straight. The major-version only changed 3 times in the past decade because 8.0 was "evergreen" for most of that time, which was also not a good strategy, yet the most obvious solution (SemVer) is always ignored by Oracle in favor of more confusing alternatives.