MariaDB ditches products and staff in restructure
theregister.com
theregister.com
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.
Perhaps even more so because Percona already pre-dated MariaDB.
Also as I understand it Percona is much closer to Oracle MySQL than MariaDB because MariaDB was a point-in-time fork on 5.5.
Can you explain why the dozens or so Postgres scale up solutions don’t use real Postgres?
Or why anyone at scale with Postgres migrates away?
https://www.uber.com/en-US/blog/postgres-to-mysql-migration/
This outage would have been a lot less likely with MySQL because of redo logs which MySQL has had for a decade. But Postgres replication is under developed. https://about.gitlab.com/blog/2017/02/10/postmortem-of-datab...
Facebook has evaluated every database on the planet and still uses MySQL. https://engineering.fb.com/2021/07/22/core-infra/mysql/
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.
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.
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.
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.
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.
People that directly experienced this very thing will probably chime in to give examples (etc). :)
A 'true' DBMS will provide some guarantees and rather fail a transaction than do a 'best endeavours' job with it.
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.
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.
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.
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.
Related blog post by a teammate: https://www.notion.so/blog/sharding-postgres-at-notion
facebook was build using pho mysql since start, by the time they have billion dollar valuation 8ts too late for them to change.
Not to mention no technical reasoning is given at all, so yes take the article with a grain of salt.
No, it wasn't, and still isn't.
MySQL supports replication correctly and out of the box, Postgres still hasn't figured this out.
(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 documents that their replication protocol can lose committed transactions. https://patroni.readthedocs.io/en/latest/replication_modes.h...
Looking real good.
As explained in the docs you link to, Postgres has both synchronous and asynchronous replication modes.
In asynchronous mode availability is favored over durability. Which means commits can get lost when the primary goes down in an uncontrolled fashion.
In sync mode that will not happen at a cost to some performance.
It’s the same trade-off any distributed system has to make, and the user gets to make the choice.
You can also mix and match sync/ascync options within a cluster and even between individual transactions.
Recent versions of Postgres have a really flexible replication configuration to cover a whole range of requirements. See e.g. https://www.postgresql.org/docs/current/warm-standby.html#SY...
Let me TLDR them for you
> Advantages of statement-based replication: Proven technology, can be used as an audit log
> Disadvantages of statement-based replication: INSERT DELETE, UPDATE, and REPLACE may not replicate correctly
Are you getting worried yet?
> Advantages of row-based replication: All changes can be replicated.
> Stored functions execute with the same NOW() value as the calling statement. However, this is not true of stored procedures.
Wonderful. Also not a problem in Postgres AFAIK because you're replicating the WAL so it doesn't need to execute it locally.
Don't forget about the pitfalls of replicating CREATE USER and ALTER USER in MySQL
https://www.percona.com/blog/what-if-the-user-exists-on-the-...
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.
Statement-based replication is deprecated: https://dev.mysql.com/doc/refman/8.0/en/replication-options-...
> 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.
(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.)
I bet AWS gets a lot of money for their DMS service for fixing this.
But looking at their financials, I get the feeling they have a "too much money" problem.
They are spending about $3M per month on "Research and development".
They are spending about $2M per month on "Sales and marketing".
They are spending about $2M per month on "General and administrative".
At a company valuation of under $50M and monthly revenue of under $5M.
Cutting down on the spending is probably the right thing.
Spending millions per month on sales and marketing and having only $5M MRR to show for it seems like the marketing is not effective.
Spending millions per month on development and not having a killer product that sells itself seems like the development is not effective.
> 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.
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.
It's widely supported, and tons of software is written on top of it -- requires it.
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.
You're right; this is like pulling the rug out from under guests you invited into your home and telling them to seek shelter elsewhere.
If you read article, Samsung.