3 ms·
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 i
by evanelias 3mo ago
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-2605214056 https://github.com/lobsters/lobsters/issues/539#issuecomment...
- edoceo 3mo agoAnd 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.
- vasco 3mo agoThis 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.
- saila 3mo agoThe 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.
- evanelias 3mo agoI 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/ https://github.com/MariaDB/ links to mariadb.org which is run by the MariaDB Foundation, not the commercial enterprise owned by K1.
- inigyou 3mo agoEven with that in mind why switch to sqlite rather than PostgreSQL, which is roughly equivalent to MariaDB?
- inigyou 3mo agoThat 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.
- jcgl 3mo agoWhat Linux distros do you think would exclude on the basis of closed door/cathedral-style development? I’ve never heard of this.
- zinodaur 3mo agoAs 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 3mo agoAny reason besides trust me bro?
- zinodaur 3mo 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 3mo 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 3mo agoYep. In 2026 I’m still hearing that MySQL is terrible because of MyISAM
- evanelias 3mo agoThe 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.