> The company won praise from analysts for the engineering behind the products.
A bit like a McDonalds fan praising an upmarket restaurant on the quality of their food.
Ok, bit of a cheapshot. In seriousness, I never fully understood MariaDB - there may have been a concern about Oracle's plans for MySQL but was that really enough to start a for-profit corporation?
And in the meantime, the big cloud vendors did a decent job of offering their own SQL options. And then we have Postgres - it was always technologically superior to MySQL but over the past few years its become as easy to deploy and run as MySQL was.
I just don't see what segment or differentiator remained for MariaDB as a for-profit corporation.
When MySQL has more users, can scale significantly more, runs some of the largest sites on earth, and even lends its storage engine to other databases like Dynamo you should backup your claims that Postgres is technically superior. Please.
Postgres has a reputation for correctness and does have some more specialized features, column, and index types. It’s also totally fine and dandy at small-medium size. Fully transactional DDL and online schema migrations put it ahead of MySQL at those scales too.
But I agree that MySQL is easier to use at high scale for its superior replication story, 3rd party tooling, and pragmatism. If you’ve only run small Postgres you don’t know the fear of the query planner suddenly going AWOL at 3am, or needing to shard your database under duress as you watch the Postgres transaction ID stick closer and closer to overflow because VACUUM won’t finish. You haven’t needed to stress out about the super low practical connection limit and build a cluster of Postgres proxies using PGBouncer or similar.
Postgres still has a ways to go for scale but has improved substantially in replication options since that 2017 article. Sharding has also seen a lot of upstream patches from enterprise db and other commercial providers since then. Upgrades in particular are still a sore spot.
Also note that folks aren’t running giant vanilla MySQL clusters. They’re running it through vitess or home grown tools with similar functionality.
Finally MySQL gets performance in these large setups by turning off features like foreign keys, acid guarantees etc. it’s awesome and powerful that you can do this in MySQL but it’s not apples to apples here. MySQL has also improved a lot on these dimensions in the last few years.
The other reality here is that on nvme hardware with a few tb of ram you can get away with a basic reader writer replica setup for a long time.
Vanilla MySQL vs vanilla Postgres. MySQL still wins on scale. You run single MySQL servers with 70,000 connections, you can't get close on Postgres because of a fundamentally broken connection-per-process model. The Neon team suggested changing that and got flamed by the community.
I was at GitHub in 2017 when that GitLab outage happened. We had 60 million users running on vanilla MySQL no Vitess at that point. We had 10 million users literally running on 3 MySQL servers. Don't pretend that even now Postgres can do that.
However, you can absolutely run that many users on a Postgres cluster of that size today on modern hardware. Connections are absolutely a sore point and probably my number one pain point as a Postgres admin day to day. Pg bouncer is incredibly easy to run though. You rarely actually need 70,000 connections most will be idle most of the time anyway it’s not like MySQL can actually serve 70,000 queries on 70,000 connections simultaneously. But it certainly makes administration and the programming model more difficult.
While MySQL being able to scale is nice and all, it's had serious problems with even keeping basic data integrity for the data people hand it... for decades.
This is the root of it all - for years and years MySQL was perfectly capable of doing the needful, but it shipped with default configurations that would do things like use "not_quite_really_UTF8" and "myisam_tables_please_no_acid".
If you knew enough to switch to innodb and "mysql_real_utf8_string" or whatever it was, you had a quite performant and stable system.
There have also been numerous horror stories where people discovered (after the fact) that MySQL wasn't storing their data as given, but instead internally silently converting it to some other format/type and storing that.
People that directly experienced this very thing will probably chime in to give examples (etc). :)
You hit the nail on the head, those were my top two complaints, but the rabbit hole goes deep.
It's not an exaggeration to say that trying to keep mysql from corrupting your data feels like a full-time job. Mysql in many ways, especially as used by massive social media companies early on was closer to a SQLish DSL for a non-transactional kv store than a "real" ACID database.
That's why "but it can do 70k rps" is just noise to someone. I don't care how fast it can lose my data.
I'm all for people needing to read the docs but man a database burns trust pretty fast when it's so easy to have it pretend to support transactions or pretend to support utf8.
That was my biggest gripe with it - at least back in the day. Back then it really felt like MySQL vs Postgres was a trade-off between 'easy but no guarantees on data integrity' and 'correct but operationally harder to manage'.
The gap has for sure closed in many areas but I still feel safer with Postgres today because there's been little reason for me to try MySQL again.
Can we restrict our discussion to the situation now. If default configs result in data corruption, that's an issue. If an older version in the past decade does, that's of less interest.
MySQL's default storage engine has been InnoDB -- a high-quality OLTP storage engine which is fully ACID compliant -- for thirteen years now.
Meanwhile MySQL's default settings have included strict sql_mode (giving a hard error on data type mismatches, overflows, etc) for eight years.
These have been available as non-default options for 20+ years, and larger MySQL users have long enabled them before they were defaults.
Yes, the defaults certainly should have changed earlier, especially re: strict sql_mode, I won't dispute that. However on the default storage engine side, the historical reasoning makes perfect sense: InnoDB and MySQL were owned by different companies. Oracle purchased the makers of InnoDB in 2005 and didn't purchase Sun (incl MySQL) until 2010. Once both products were owned by Oracle, they made InnoDB the default storage engine in the next major MySQL release that same year.
In any case, your claims of "decades of misleading marketing" about transactions is completely fictional. This simply did not happen for "decades" and has not been a discussion point of any sort for a very, very long time. Serious MySQL shops were never using MyISAM at scale in the first place.
You chose to come into a thread about MariaDB, you wrote some verifiably factually incorrect statements about MySQL, and then you complain about not having the energy to discuss further?
I took time out of my Sunday to write a fact-based rebuttal to your false claims in this thread. The dates in my comment are all verifiable on Wikipedia, among other places. And yet your response is childish repetition, followed by a citationless comment claiming that my own comment was misinformation.
Since you're a Golang enthusiast (as am I), perhaps I can reframe this in a more relatable way. Imagine that it's the year 2035, and there's an HN thread about Golang. Some Go-hater chimes in that no one should ever trust Go because of decades of misleading marketing ("no one needs generics!"), GOPATH being stupid, and lack of a module dependency system. What would your response to this be in 2035, knowing full well that these issues were far in the past and that the claim of "decades" is at best an extreme exaggeration?
A decade is 10 years. Plural decades means 20 or more years.
You claimed MySQL made decades of misleading marketing about transactions. That would mean they were making such statements in 2015 or later.
That is verifiably factually incorrect, considering that InnoDB (a fully ACID-compliant storage engine) was made the default storage engine in 2010, and prominent MySQL users had already switched to InnoDB en masse from 2005 to 2008, some even earlier. The previous storage engine (MyISAM) was garbage that wasn't even crash-safe, so at scale its deficiency was plainly obvious.
I am not posting "bullshit" or "trolling". Your statement was incorrect and this is simple date math.
I have 5 million users running on PostgreSQL, 3 dedicated servers (primary + 2 replicas), we use less than 190 connections, vanilla PostgreSQL and no things like pgbouncer.
> Finally MySQL gets performance in these large setups by turning off features like foreign keys, acid guarantees etc.
Large MySQL users are generally not turning off acid guarantees. That is nonsense. What settings are you even specifically referring to with this?
On the durability side, large MySQL shops only mess with innodb_flush_log_at_trx_commit if there's a safe distributed durability mechanism in use (e.g. synchronous or semi-synchronous replication). Or perhaps if the data is ephemeral/recomputable, but that's a similar use-case to running Postgres on a ramdisk.
On the isolation side, MySQL supports READ UNCOMMITTED (unlike Postgres) but it is very rarely used. Only useful for some specific situations. fwiw MS SQL Server supports it too, it's not a MySQL specific thing.
A single departing employees opinion is not definitive, no. Considering both YouTube and Facebook use modified MySQL I’m skeptical there’s some inherent structural disadvantages.
Not to mention no technical reasoning is given at all, so yes take the article with a grain of salt.
Postgres replication features have lagged behind but were never dangerous.
MySQL has multiple edge cases where things on the master will not happen on the slave depending on which replication method you've selected and which features you're using. MySQL is the issue here.
> Replication is the #1 important feature for any setup that is larger than one server
That's... just replication. And postgres handles replication fine in my experience, I could in fact say the opposite about MySQL. What issues do you have with it?
Postgres doesn't handle replication fine. It has two replication mechanisms, and both lack critical features and are broken by design.
(Most of the problem comes from the fact that Postgres hasn't figured out that they need a standardised replication event wire protocol to do this correctly.)
Please do say the opposite about MySQL. Tell us what is wrong with it? Linkedin use MySQL replication to ship data across regions and rebuild caches the other side because other protocols are too unreliable.
MySQL has improved things in recent years but this list used to be much larger. Just go look through their bug tracker. It's not something that instills confidence and I need to deploy databases I can trust will not eat my data. I've had too many customers with broken MySQL databases over the years and zero with Postgres.
> Stored functions execute with the same NOW() value as the calling statement. However, this is not true of stored procedures.
That's from the "disadvantages of statement-based replication" section, not the row-based replication section. So to recap, the disadvantages you've quoted from the manual are specific to statement-based replication, which is deprecated.
> Don't forget about the pitfalls of replicating CREATE USER and ALTER USER in MySQL
As mentioned in that Percona blog post, all you need to do is add IF EXISTS / IF NOT EXISTS to your SQL and it solves the problem. Or in MariaDB, you also have the option of CREATE OR REPLACE syntax.
Sure, it's a minor footgun for newbies, but not exactly a horrendous problem.
MySQL can actually do one better which is semisync. The transactions get replicated synchronously but applying them is async. You can't lose data anymore due to a primary failure.
There's hundreds of thousands of small companies out there that run a mariadb database that needs support. That's who mariadb sells to. Consequently, they have a lot of very small customers all over the world.
But MariaDB is not selling to them. They are now only selling their enterprise version of MariaDB with ”Contact Us“ pricing. So those hundreds of thousands companies will not be a paying customer.
10-15 years ago, the MySQL cli has was far more user friendly than PostgreSQL. I don't remember the specifics, but I found postgres pedantic and lacking shortcuts that made life easier. That said I liked PHP too.
Sun Microsystems paid some billion to MySQL authors that then decided to have more fun with MariaDB and started to compete with Sun/later Oracle again. Not sure where did the billion go if MariaDB is now in need to raise debt...
> Earlier this week, the company also announced a new finance package [PDF]. RP Ventures has agreed to a $26.5 million "senior secured promissory note" – a form of credit agreement – at an interest rate of 10 percent per annum.
> The facility will be used to pay off a European Investment Bank loan, with a maturity date of October 11, 2023.
> The new VC loan has a maturity date to a maximum of January 10, 2024.
I'm no business expert but this strikes me as the corporate equivalent of taking payday loans to make your car payment.
CMO terminated the same day, so I'm assuming their marketing department largely was gutted as well while they figure out how to rebuild their image.
It looks like they're taking the route of just focusing on enterprise customers, which seems risky given the competition in that space is already fairly entrenched and dominant.
Personally, I don't see them lasting another 5 years. At least, not thriving.
Yes I thought managed databases were the holy grail of database monetization. How bad were the cloud services that they were providing? They seemed to put quite a lot of effort into that part of their offering too.
It's clearly part of the problem that practically nobody in this thread even know WTF Xpand(formerly Clustrix) is, and are judging MariaDB Inc's actions largely on a "why MySQL fork" basis.
My ex-colleagues from Clustrix who stayed on-board through the MariaDB acquisition have all been recently #opentowork and talking of getting terminated on LinkedIn. Not marketing people, these were the engineers maintaining Xpand.
The Xpand/Clustrix tech is far more interesting than any of MariaDB/MySQL/Postgres, but proprietary.
I'm personally vested in xpand...I don't know what state its in now, but it would kind of suck if it just got put in a dusty cardboard box in the back of a storage unit.
Some amount of customers bought into the cloud offerings, which are now being sunset. Meaning those customers now have a forced migration to something else. Will they now trust the company and pay for enterprise licenses (and figure out how to host it), or is there enough distrust that they migrate to something else like AWS RDS/Mysql?
So just price MariaDB 20% cheaper than MySQL and ride off into the sunset on enterprise earnings? No innovation needed. I wonder if their PostgreSQL compatibility layer can be used with MariaDB outside of the cloud, and if that has any benefits.
Founder pride issue. Started another MySQL once out of Oracle. He should have focus on improving MySQL+PostGreSQL+whatever NoSQL out there. Instead, he wasted resources to build another instance of MySQL. But to his credit though, his action forced Oracle to behave well with MySQL and not decimate it like OpenOffice, once upon a time.
A bit like a McDonalds fan praising an upmarket restaurant on the quality of their food.
Ok, bit of a cheapshot. In seriousness, I never fully understood MariaDB - there may have been a concern about Oracle's plans for MySQL but was that really enough to start a for-profit corporation?
And in the meantime, the big cloud vendors did a decent job of offering their own SQL options. And then we have Postgres - it was always technologically superior to MySQL but over the past few years its become as easy to deploy and run as MySQL was.
I just don't see what segment or differentiator remained for MariaDB as a for-profit corporation.