3 ms·

The comparison with MySQL/MariaDB is unfortunate, given that since the "split" MariaDB has shown itself to be every bit the corporate owned "FOSS" project while

The comparison with MySQL/MariaDB is unfortunate, given that since the "split" MariaDB has shown itself to be every bit the corporate owned "FOSS" project while its supporters still harp on about how terrible oracle is for OSS, without actually acknowledging the real history of each respective project and accompanying company. Given that MariaDB the company is now owned by a private equity firm, I doubt it's going to get better.

Intermernet 4mo ago
Still got Percona, but I'm not sure what their status is at the moment.
- stephenr 4mo ago
  To me the biggest "unknown" with Percona is that MariaDB (the company) bought out Codership (the creators of Galera Cluster, which XtraDB Cluster is based on) and it doesn't seem to be OSS any more. I'm sure for some shops this will drive them to pay for the same feature in MariaDB cluster, but I'm more likely to just transition to MySQL Group Replication. This is my whole point about MariaDB - they are steadily making their OSS software completely dependent on the company (paid) versions for anything beyond toy scale.
  - evanelias 4mo ago
    I don't think your last sentence is fair. Many workloads don't need something like Galera, as standard async replication scales to extreme levels, and you can achieve excellent HA with external orchestration and/or proxies. FOSS MariaDB is definitely not toy-scale only. Oracle has also been guilty of locking modern table stakes behind the MySQL Enterprise / Heatwave pay gate, such as vector indexes and JS stored procedures. 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. And a couple days ago Oracle announced that they're nonsensically changing their MySQL versioning/LTS naming yet again. So now the way you identify an LTS is "major version is an even-numbered last two digits of a year, while minor version is exactly 4 to represent LTS releases always being in April." So for example MySQL 28.4 will be LTS, but 28.7 and 28.10 are not. But prior to this, 9.7 and 8.4 are LTS, and 8.0 was de facto LTS but now EOL. It's bizarre. I wish I was joking!
    - stephenr 4mo ago
      > 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.
      - evanelias 4mo ago
        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.
        stephenr 4mo ago
        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.
        evanelias 4mo ago
        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.

Intermernet 4mo ago

Still got Percona, but I'm not sure what their status is at the moment.

stephenr 4mo ago
To me the biggest "unknown" with Percona is that MariaDB (the company) bought out Codership (the creators of Galera Cluster, which XtraDB Cluster is based on) and it doesn't seem to be OSS any more. I'm sure for some shops this will drive them to pay for the same feature in MariaDB cluster, but I'm more likely to just transition to MySQL Group Replication. This is my whole point about MariaDB - they are steadily making their OSS software completely dependent on the company (paid) versions for anything beyond toy scale.
- evanelias 4mo ago
  I don't think your last sentence is fair. Many workloads don't need something like Galera, as standard async replication scales to extreme levels, and you can achieve excellent HA with external orchestration and/or proxies. FOSS MariaDB is definitely not toy-scale only. Oracle has also been guilty of locking modern table stakes behind the MySQL Enterprise / Heatwave pay gate, such as vector indexes and JS stored procedures. 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. And a couple days ago Oracle announced that they're nonsensically changing their MySQL versioning/LTS naming yet again. So now the way you identify an LTS is "major version is an even-numbered last two digits of a year, while minor version is exactly 4 to represent LTS releases always being in April." So for example MySQL 28.4 will be LTS, but 28.7 and 28.10 are not. But prior to this, 9.7 and 8.4 are LTS, and 8.0 was de facto LTS but now EOL. It's bizarre. I wish I was joking!
  - stephenr 4mo ago
    > 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.
    - evanelias 4mo ago
      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.
      - stephenr 4mo ago
        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.
        evanelias 4mo ago
        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.