[evanelias]

Some of the cited reasons for moving off MariaDB [1] seem misguided, in my opinion. Especially the part about "K1 are very enterprise-focused, so the database is likely to focus its work on features that are not relevant to us. There's increased risk they drop the free/open source version we use"

K1 acquired the commercial entity behind MariaDB Enterprise, but that's separate from the non-profit MariaDB Foundation. And there's literally zero risk of the MariaDB server suddenly going closed-source; as a fork of MySQL (which is GPL), this is not even legally possible!

[1] https://github.com/lobsters/lobsters/issues/539#issuecomment...

[saila]

The GPLv2 doesn't prevent a company from distributing binaries and making the source available on request while development is done behind closed doors. This wouldn't really be "open source" as we typically understand it and might be cause to exclude it from some Linux distros, for example. I'm not saying that K1 would do this (I have no idea who they are or what they do), but I also think it's a reasonable risk to consider.

[inigyou]

That was precisely how the original free software movement started, actually. Work was done behind closed doors and if you didn't like it, you released your own version with your changes.

[evanelias]

I don't see how that would be a realistic risk? Any MariaDB user (including Lobste.rs) could request the source, and per the GPL it must be supplied, so this isn't an effective strategy for any entity to go closed-source.

And in any case, https://github.com/MariaDB/ links to mariadb.org which is run by the MariaDB Foundation, not the commercial enterprise owned by K1.

[inigyou]

Even with that in mind why switch to sqlite rather than PostgreSQL, which is roughly equivalent to MariaDB?

[jcgl]

What Linux distros do you think would exclude on the basis of closed door/cathedral-style development? I’ve never heard of this.

[edoceo]

And even if it did go closed-souce, your existing install can run for ages because the vendor cannot force upgrade. One of my favorite features of FOSS.

[NuclearPM]

How could it go closed source?

[c45y]

Probably in the way Minio did. Technically the source is still available but the controlling entity behind it have shut down all changes

[zinodaur]

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

[evanelias]

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]

Any reason besides trust me bro?

[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

[vasco]

This makes little sense but I guess they get little traffic so pretty much any database will work for them.

If traffic grows they will find problems, then limitations, then move to postgres. And if not it's fine. Story old as time.