In comparison to other cloud companies, AWS "deprecated" SimpleDB over a decade ago and stopped letting new people use it, but still hasn't deleted the data for anyone that is still using it. EC2 Classic was the same.
Not giving updates and not allowing customers to create new instances is one thing, and is normally how these big deprecations are done. Outright destroying your customers' data just because they didn't migrate in time is wild (and its very easy for something like a database migration to take much longer than 2 years).
in comparison Azure depreciated Azure classic VMs in 2014 and just last month stopped letting customers run them. If it takes you more than two years to plan and migrate a DB your likely not running it on MariaDB and if you are there are plenty of consultants that can migrate your apps back end in less than two years. Hopefully if you are running a db you are also backing it up so the idea that data is being destroyed is a bit dramatic.
There also other cloud companies to depend on that have been more sane. I doubt that in practice this will cause huge insurmountable challenges, but it's a headache and not a ton of fun.
If you are willing to let two years pass by and then allow your database to get completely deleted, why wouldn't you rather take a small hit on delivery of some other projects in six months, possibly face a small amount of downtime, and migrate away so you get to keep your data?
Who knows if one would still be working in this project/ team/ company?
Nobody gets good raise/ promotion for maintenace or migration work. Some pat on the back... May be.
I mean is it perfect? No. Are there better solutions and practices? Yes. But is it crazy and is it gonna cause irreparable damage? It is not unless you’re very irresponsible as a consumer. Either way that’s just my opinion.
2 years? Have you seen how long databases last in this industry? I worked at a place that had been rocking the same original NoSql precursor for at least 4 decades.
Time is money. A migration could easily require code changes + testing, which can add up. If you're a small business that has to outsource this, I could see the cost of migration costing more than their aggregate DB hosting costs so far.
I'd expect them to migrate mariadb to mysql in the backend eventually, offering a managed migration path for people who want to do it on their own time (ie not wait for an abrupt disruption at some random time in the next couple years)
I don't know anything about this, but I'm near this on the postgres side of azure. On that end I've seen a couple transparent migrations & have been working on less transparent ones too (such as pg11 eol). This handling of mariadb casts a bad light on the db services as a whole that doesn't match what I've seen previously
When you rely on “cloud”, this is just an inevitability.
It’s nothing new at this point. MS is such a huge org, they can tank the bad PR. Save on hosting, support, and bandwidth costs of MariaDB. Ultimately saving much more in $$$.
Think about liability here. I'd you are not supporting database and nor patching security holes in it it is very likely you can be hold responsible for security incidents.
I think it is fair instances no longer operate though perhaps taking backup of the data before deletion would be good
Even on "slow enterprise" timescales, 2 years should be more than sufficient. Doubly so given whatever you're using MariaDB for you can almost certainly just use MySQL instead. It's not like you have to go use a fundamentally different database technology
For some of us, being completely locked in is an explicit objective. We brag to our customers about the fact that our only major technology vendor is Microsoft. We use AWS but only incidentally for things Azure isn't fantastic at right now.
It's nice not having to constantly think about what to paint on the canvas. If you allow them to, Microsoft can completely guide your IT journey. If you don't constantly dig your heels in and keep your arms and legs inside the ride, this generally works out. The part where it gets shitty is when you absolutely insist on fighting against their patterns. You may win in the short term, but you have to be prepared for the long term effects and downstream frustration.
A good example of the "don't fight it" for us was throwing away our custom logger in favor of Microsoft's application insights crap. I don't like it in nerd terms (because I still think the custom system was better in most ways), but in business terms, it's infinitely better for all involved - The chances I can find someone on LinkedIn who can manage my Azure logging infrastructure are infinitely greater than finding someone who has experience with my custom logger's private repository.
>We brag to our customers about the fact that our only major technology vendor is Microsoft.
If anyone bragged to me about this I would laugh in their face. You're putting your entire company at major risk.
Sometimes it has benefits, and sometimes its necessary, to use something like Azure. But I would never actively seek tying your existence solely to a single company, nor would I be happy about it. And I would certainly never _brag_ about it. That's insane.
I assume the poster to whom you're responding just hasn't been in the industry long enough to understand that the entire point of gigantic platforms like Microsoft or AWS is specifically to create ecosystems of vendors that provide service around that platform.
You can tell by who is fighting the current. Some get paid in ideology, some in fiat. Which are they here for? That's the question. I'm just here to get paid, and enjoy working with others desiring the same outcome (strong opinions weakly held while bank acct goes brrr). We can chat war stories at the hotel bar with a comfortably large investment account from the work.
Unethical implementations are distinct from agnostic technology implementation choices. I don’t care about the underlying tech (Windows, Linux, Mainframe), but I’m certainly never working at Meta, for example. New FedNow instant payments runs on a mainframe. New hotness? No! Built to run for decades? Yes.
Meh. That whole issue is way overblown by the twitter researcher types trying to build buzz and make a name. It's a serious issue don't get me wrong but security incidents are a question of when not if and the dialog surrounding the issue doesn't come across as charitably capturing the scope and impact. Microsoft's response, which has been to handle the issue responsibly is far from the "radio silence coverup" and "the attackers are still in the network" and "you can't trust anything Microsoft signs anymore" reality you'd be inclined to believe if you only read the hype angle and believe the alarmist comments from other "any chance to bash on M$ is a heyday" types.
I hadn't seen the article you linked though and will say it seems to be in good taste.
>Every company and every vendor has strengths and weaknesses.
Yes, every company and every vendor does have strengths and weaknesses. That's why it's foolish to lock yourself in to only one vendor.
If you locked yourself in to AWS, for example, you'd benefit from some great AWS services, but be stuck using the awfulness that is Workmail/Workdocs. Or you could lock yourself into MS and get Outlook/Office, but then be stuck using subpar offerings like Azure Functions or be a victim to their lackadaisical attitude towards security. Why would you ever choose to do either of those? Instead, you can choose both Microsoft for Outlook/Office, and AWS for other offerings that they are stronger at. Now you benefit from the strengths of both, while avoiding their weaknesses.
If you _can't_ do that, there might be good reasons and that's fine. But to _intentionally_ not do that, and especially to _brag_ about not doing that is laughable, no "holier than thou" attitude required.
more power to you if you made a career on MS technologies, for a long time they were the big dog on the corporate world but to be fair there are better options there and actually bragging about vendor lock-in is ridiculous, if you're full in and it works for you good! But its not something to brag about, specially since MS refuses to fix their certificates after they got hacked by China
@danseop08 Stuck? What a weird and interesting thing to say since I deliberately chose and applied for jobs I was not only good at, but had the most experience in. And to then add in that I haven't seen anything other than Microsoft to boot?
Don't you think that over a 30 year tech career that I've touched and used many different products and technologies?
Very bad rebuttal. You effectively just demonstrated you got stuck with MS for 30 years. You have not seen any others other than MS. You likely downplay the bad and overtly having good image of MS. My experience with multiple cloud systems CANNOT conclude Azure in the top 5. At best maybe 6th with occasionally hitting 5th or 4th depending on some specific tech metrics.
> You're putting your entire company at major risk.
We use AWS but, the same argument applies here. It's far, far, far more likely that the developer who implemented the solution leaves than AWS or MS pull the rug from under us.
Given the choice between setting up an ad-hoc solution with one developer, or using an existing managed offering, putting all your eggs in an employee when they have an average tenure of 2 years is _way_ more risky.
Larger enterprise customers have problems with vendor finger pointing. Let's say you have a database transaction that intermittently fails and you decide to (pay) ask your vendors to help. The DB vendor says it must be the network or application, the network vendor doesn't seen any problems, the application platform vendor or consultant says it must be the network or database. Even getting all these people on one call takes a lot of time and isn't helpful.
Honestly Microsoft isn't any better, but if buy Premier Support (expensive), you can eventually talk to the actual development teams. You also get a person in a suit who will talk to your execute team and take the blame, which is an important feature for managers.
If you work in a regulated environment it's so much easier to explain to a regulator that you work with a single SOC 2 compliant, ISO 27001 certified cloud provider rather than a mishmash of services.
My expectation would be that anything other than Microsoft offers higher risk. They will most likely be around for a long time, and they keep their products around for a long time, with proof of focussing on backwards compatibility. Is it without risk? Probably not, but i doubt you can show me a IT company with lower risk.
My experience was that salespeople bugged managers who bugged me to use cosmos because or course I want to use Microsoft's take on Mongo.
It wasnt just that. They also advised managers to enforce the use of teams for security reasons - which is a bit like advising that you install windows for open source reasons.
And while SQL server worked fine, postgres and mariadb were initially "unapproved" for security reasons and dog slow once they were (& support couldnt help for some reason).
In business terms Microsoft seems to be basically be a rebranded Oracle - playing an elaborate game of vendor lock in using every trick available while trying to maintain a thin veneer of deniability, circumventing the need to compete on the quality of their software.
Now if youll excuse me I have an unwieldy YAML github actions mess to unwind so we can move to a different CI platform. I wonder why they let it get so bad.
> I can find someone on LinkedIn who can manage my Azure logging infrastructure are infinitely greater than finding someone who has experience with my custom logger's private repository
Why not do something standard with no platform lock-in?
We do structured logging and push them to an Elastic stack with fluentd. For now we use an Elastic we deployed on a Linux VM but 1) we can move at any time, either from cloud provider, or stop using Elastic if we want to, and 2) we can probably find more people who can manage that than whatever Azure solution you’re using
I see no reason for getting locked in for something like logs. We actually did that with AWS Cloudwatch at some point and it was a horrible experience
I can't speak for the whole platform but when we were having problems with S3 uploads, I evaluated both GCP and Azure. Both were better and Azure seemed best possibly because they didn't have different tiered services (only the good one). We ended up going with GCP at the time because of specifics of resumable uploads IIRC.
Curious to hear more of your thoughts on Application Insights.
I've always been fond of it due to how much it gives you straight out of the box.
I'm on AWS now and sadly it doesn't seem to compare whatsoever. A custom solution seems like it would take a fair bit of effort just to reach basic parity.
I haven’t done much with Azure. Out of curiosity, do they offer any AWS API compatible service, in the same way that Backblaze B2 has an S3 compatible API?
However for a business this is very definitely a valid stance to take (as covered by some sibling posts). To dismiss it out of hand is a failure to accept that business priorities and concerns can, and often do, differ from technical ones.
I had to check your post history to confirm you’re the same person who was preaching Microsoft in the thread yesterday. You’ve got a major case of Stockholm syndrome bröther.
We've had to warn you about that before, and also about other guideline violations recently. Could you please review the rules and stick to them? https://news.ycombinator.com/newsguidelines.html
Because they did an analysis of what was offered and what it cost and determined it was the best fit. Coupled with the fact that it’s run by the company with the best reputation in tech for backwards compatibility and you have a pretty compelling case.
They are giving two years notice. With a clear migration path with step-by-step instructions (linked in the article). And since MariaBD and MySQL are more-or-less drop-in replacements of each other it should also be a painless transition for most.
That's not perfect, but much better than when last year GCP retired IoT Cloud Core with just one year notice, a much less public announcement (an email to affected customers and a note on the product page) and no clear migration path.
> since MariaBD and MySQL are more-or-less drop-in replacements of each other
Not anymore for a while, unless application developer has been very careful in using DB features.
Also, there are things like how indexing differs in two.
If ORMs have been used, without a good DBA being available... there are many landmines on the migration path.
I think this is an interesting take people have on large companies in general, but tech companies specifically - as though everything they do is perfectly planned and executed, and is the most reasonable course of action
It might surprise some people to learn that companies are made up of humans, who have various biases, and are subject to various pressures - like politics and bureaucracy - to produce certain results. Not every decision they make is inherently going to be the best decision
I can give you one reason: Amazon is also a competitor to many online retailers. Putting your business in the lap of a competitor is not something you do lightly.
In contrast to my comment above about Azure taking care of the people who pay the bills, GCP's design around the billing and understanding spend UX is absolutely the most hostile of the big 3. Their design choices around hardware reservations and aggregating resources in the bill that make it impossible to understand what cost what is frustrating to say the least.
I've found GCP to be extremely expensive bandwidth wise, however the network is also really good. So I suppose it's understandable that they'd charge a premium.
Because Google Cloud don't care about their customers and have zero support. Srsly educate yourself on the horror stories about businesses built on Google Cloud having their account catastrophically, irrevocably deleted with zero explanation or ability to talk to anyone about it.
I'll tell you what Azure does better - way better - than the other big 2 American vendors: they make it vastly easier for the people who pay the bills to understand what's going on (without having to spend 10 years as a Devops engineer first).
This is what I've enjoyed about Azure the most - it's all quite simple. However, due to accounting shenanigans our entire company is going to migrate from Azure to AWS. I'm extremely curious as to what that transition is going to look like.
I would consider AWS, Google Cloud and Azure to be very similar products. There are many pros and cons for each, but no general red flags for any of them.
What's wrong with them? If you happen to have some sort of microsoft dependency, they are a good choice for you. Not perfect, as any other cloud provider, but a good choice nonetheless.
My experience is that it's night and day... in favor of Microsoft. Caveat is that I'm on the data side, but AWS is a hodge podge of open source projects that they "integrated" (poorly). There's issues with data type mismatches between glue catalog and Athena/Presto, you can throw your data into Redshift but that's behind its own security curtain in postgres. You can move your data via glue, emr, MWAA, etc. but they all feel bolted on and integration is always more painful than it needs to be.
Microsoft, meanwhile, is moving towards synapse and fabric which is just everything you need in one spot, (more) easily integrated. I'm not saying it's perfect, but the vast, majority of companies I've worked with don't have the expertise or desire to put together some bespoke architecture taking into consideration the 5 options they have every single step along the way. They want something they can use out of the box.
In my experience (sticking to base services like vm, k8s and blob storage) they are more reliable than GCP and less confusing than AWS. They're managed offering is bad, but I don't touch managed services anymore after getting burned by them several times.
The Azure SQL Server offering is spectacular. I've been using their multi-region replication, and they offer point-in-time restores if something were to happen.
Also, they have really good documentation for high-availability (e.g., paired regions)
Less confusing than aws? I had such a hard time with enterprise apps, AD apps, service principals... And you kind of need to use Azure AD to manage resources and access for tons of products.
I generally pick AWS, but Azure is a close second and we use it for specific things too. Aside from GPT access, Microsoft gets compliance right. Working with medical, military, or some types of educational, Azure is a better choice.
I like that things I did over a decade ago on AWS still work. I don't like that Google throws me on the curb every few months. Azure is in between, but closer to AWS. 95% of the cost is maintenance, so AWS > Azure >> Google.
Same reason companies switch to Teams: Microsoft gets mindshare of controllers and executives with nice sounding bundle discounts (they're usually already using Azure AAD and/or Office 365) on a supposedly fungible services that really are not. Usually they are much worse.
Alternatively, one may consider a SQL Server database. The reason for that somewhat unusual choice is managed Azure SQL databases for just $5 per DB, which is insane value for a managed database with a guaranteed service level.
I always search for something comparable in terms of value, but always fail.
MSSQL was also very cheap while Microsoft was trying to break into the database market. A few years later it turned into one of the most expensive options available. Vendor lock-in is never cheap.
Or maybe that's just how I read paragraphs like this:
> MariaDB is more scalable and offers a higher query speed when compared to MySQL. This makes it good for managing large-sized data. You will also find more features in MariaDB that MySQL doesn’t have, like sequence storage engines and virtual columns. You can also use multiple engines in one table.
> However, MySQL has been around for much longer than MariaDB. Some organizations prefer the enterprise support that MySQL offers.
Some information in that post is out of date -- for example, MySQL has supported virtual columns for eight years now.
Other things in there are a bit of a head-scratcher. Using multiple storage engines in one table is a terrible idea ACID-wise, since each storage engine has its own separate transaction implementation (if it has one at all). If I was to list meaningful features in a MySQL vs MariaDB comparison, that one wouldn't make the list at all...
In any case, AWS built Aurora on MySQL and not MariaDB. There are numerous possible reasons, but it seems like an important data point to consider.
I wouldn't classify it as "ape shit", but the MySQL connector used to be LGPL. Now that's it's GPL any software that bundles it needs to be GPL as well. I'm guessing that Oracle has contacted some companies about commercial licensing. The alternative is to just use the MariaDB connector, which is still LGPL and is MySQL compatible.
If you're not distributing your software, then yes, it's fine. It's mainly an issue for companies who license their software to other companies.
Even if you don't distribute your software it's good to be at least aware of your bill-of-materials. If your company decides to pivot and start licensing out the software then you want to be able to flag any issues like this quickly.
GPL forbids you from using this library in a commercial product (any product that doesn’t use a compatible FOSS license) without buying a commercial license from Oracle.
The PostgreSQL JDBC driver doesn’t present this problem to you.
You can use it in a commercial product, but if you distribute the commercial product it's going to require you to adhere to the GPL, which obviously has practical implications.
You can use it in an internal product that you use commercially, even if the program interacts with external users (e.g. web server) which is a big reason why AGPL exists.
Although, it's best to aware of what internal tools and software may require GPL distribution. For example it's the position of the FSF that distribution of internal tools to contractors requires adherence to the GPL.
The other thing I think is so interesting is how Microsoft refers to these databases as their "open source" strategy. The amount of Open Source-washing Microsoft gets away with with its strip mining is so out of control to me.
I'm looking forward to certain OSS zealots in the database support for $$$ industry coming in here and defending this. Folks will happily defend the strip mining and then try and go after the scraps
Probably related to the mariadb company debacle. Without mentioning how Mariadb made changes in the last months and years to make it incompatible with mysql
No, MariaDB is a fork and has meaningful functionality differences from MySQL. They've been diverging for over a decade and aren't drop-in replacements for each other.
Meanwhile Percona Server is a drop-in replacement for MySQL, essentially it's a large patch-set on top of MySQL rather than a fork. Percona Server releases line up with MySQL releases and versioning. Whenever Percona Server features break binary compatibility, it's explicitly noted in their manual, and not enabled by default.
Is it actively incompatible or are MySQL and MariaDB both just continuing to develop by implementing slightly different subsets of PostgreSQL (reading change lists for the two of them feels a lot like that from my pg-biased POV).
At least they're not trying to upsell you on MSSQL as a blatant slap in the face, rather they're just pulling the rug out from underneath you. Must be a profit sharing arrangement with Oracle trying to drive people back to MySQL.
Oracle must have given them a good deal. (I wonder if this is the future of the "Cloud" - the slow phase out of all open source software with BigTech corporate software to "tie" you in and exploit the data - for ai, prism etc. - with privacy invasive Terms of Services and questionable "privacy policies"?
for such an anti-customer change; the lack of depth in their announcement is terrifying. Perhaps their impacted customer base is so low they just don't care, but if this is all they're putting out about it shame on them. i have no horse in this race; happily existing in AWS w/o issues. :D
I worked mostly in closed source RDBMS so I do not have so much experience in those open ecosystems, my question is why MariaDB still a thing in a world with Postgres or MySQL?
MySQL is still a thing because of inertia. Back when projects like Wordpress or MediaWiki were started, MySQL was the only good free option (postgres had a reputation for being slow back then). As a consequence most of the PHP ecosystem is on MySQL. And despite not being hip in Silicon Valley, PHP makes up a massive portion of the internet.
Also MySQL makes some different tradeoffs than other databases, and while some of those may eat your data they can also make MySQL the best choice in some situations.
MariaDB is an attempt at a better, freer, faster fork of MySQL, viable as a drop-in replacement. That comes with all the expected drama around the MySQL/MariaDB choice and the companies behind them.
I wouldn't switch because I don't think they're different enough to see a point, but unless there's a specific feature in MySQL but not MariaDB that I anticipate needing, I've been tending to default to MariaDB for new projects.
Not going to happen. I don't like how InnoDB lays out data on disk.
MyIsam and Aria tables are so much nicer with the data structured logically in files which hold the data of individual tables and directories which hold the data of individual databases.
The opposite of true. InnoDB updates the memory view and writes a journal; then it writes the disk view; it maintains a highwater mark for the journal somehow, not sure I care. MyISAM just writes the disk view; no journal is written.
So what happens with InnoDB as writes increase is that eventually you get freezes while the disk view catches up, which frees up journal space so it can go on another writing spree. If you try to shut down the database during one of these freezes it hangs. If you force it to restart anyway, it immediately freezes again on restart... until it frees up some journal space. Paradoxically in this case you have to decide how long of a freeze you can tolerate and reduce the size of the journal(s) accordingly.
MyISAM doesn't write the journal, so it doesn't have journal writes. "Half as many writes" is the best case, in practice there are additional writes pertaining to indexes. (You can be even more clever and disable updating indexes or even drop all indexes and re-create them after all table writes are completed. You can even write to some temp table, build the indexes on it, then rename it to the actual table; or fail over to a new node with the refreshed tables.)
Everything I know about tuning InnoDB I learned tuning DEC RDB (based on the KODA engine, Oracle bought RDB to get the KODA engine for its distributed locking implementation), not much has changed in 30+ years.
Ok but row level locking. I love this conversation btw. We could be having this same discussion in 2013 with seemingly very few differences. Shows what shit oracle’s stewardship of MySQL has been.
Ok but mtbl. There's a whole culture devoted to immutable (write once) databases at very large scale. There's another whole culture which thinks ACID shouldn't apply to distributed systems and that global context should be avoided.
In the context of cloud, (MariaDB versus MySQL) what both brand options offer is multiple engine support. The cloud tends to offer its own engines, under its own brand(s).
For initial bulk file loads using mysqlsh [0], MyISAM doesn't stand a chance because it takes a table lock, so the tool can't parallelize the import like it can with InnoDB.
I wrote a small script to test this [1]. tl;dr 12,500,000 rows totaling 2.75 GB took 6 min 57.2374 sec at 6.59 MB/s for InnoDB, and 11 min 18.4550 sec at 4.05 MB/s for MyISAM. During the test, whereas the InnoDB load utilized multiple cores, the MyISAM load only saturated a single core.
Now, normal INSERTs are likely another story. Working on that test now.
Python script [0] to do bulk INSERTs. I TRUNCATEd the tables, chunked 10,000 INSERTs at a time, and recorded the results. This was split into two passes of 12,500,000 rows each, committing after each chunk of 10K rows.
tl;dr On an empty table, InnoDB is 1.7% slower than MyISAM. On a full table (I raised bulk_insert_buffer_size to 128 MiB, which is a MyISAM-only optimization, and is more than enough to handle 10,000 rows of my data [21 MiB]), they are effectively identical, with InnoDB being 0.1% slower than MyISAM.
It's worth noting that this is with InnoDB's defaults for doublewrite enabled. If (and only if) you're using ZFS, you can disable that, and get an enormous speed boost. These data dirs are on XFS, so I didn't disable the doublewrite buffer.
Finally, I tried some simple `SELECT COUNT(*) WHERE user_id <= ...` - `user_id` is the PK and a UUIDv7, inserted in order so as to avoid page splits for InnoDB. Not as familiar with MyISAM's page layout, but I assume it at least isn't _hurt_ by ordering on insertion. The value selected was near the end (~1000 away), so it had to do a huge covering index scan.
For InnoDB, I saw [22.01, 22.39, 22.69] seconds. For MyISAM, I saw [27.12, 27.53, 26.81] seconds.
If you're able to give me some specific workloads, or settings to tweak for MyISAM, I'm very willing to redo the test, but as of now I'm unconvinced that MyISAM has an edge.
It'll probably take me longer than you'll maintain interest in this thread, but I'll reply when done anyway.
I've created 3 tables with an auto-incrementing unsigned bigint as the PK, and then 4 unsigned int fields with random values. Each table has 25,000,000 rows (and has unique values, modulo the PK). Once they're loaded, and I come up with some queries, I'll create some indices, and then reduce the buffer pool to < index size to mimic those conditions.
That could be of the transactions, innodb will keep your data reads intact (of that is not of importance, if the update is more important than the result based on the current state of the data, for example with
UPDATE SET field = field + 1)
You could maybe have matched with a change in the transaction isolation level for innodb
This. Please do not do this on a production DB for reasons like "I like the file layout more" without knowing what you're losing. Write performance on MyISAM is often worse than using SQLite, for instance.
Aria can be "crashproof" by using what I think is effectively a mini-WAL.
"One statement per transaction" is a limitation you need to be able to accept, but -if- that's the case the data safety is likely relatively fine.
MyISAM, much like pre-wiredtiger MongoDB, sits firmly in the "probably don't put anything into this you can't recreate" category for me.
Also remember that filesystems are much better at leaving something consistent behind (maybe consistenly broken, but that's still often better for getting things fixed) even after a nasty crash than they used to be - so while the last time I used MyISAM many many years ago we did absolutely get data loss issues, I wouldn't be surprised if we'd've lucked out if we'd had a 21st century filesystem instead of UFS.
> Are you trolling? Both MyIsam and Aria are not ACID compliant. May as well use /dev/null.
This is silly. I would say most databases in production in the world have zero need for ACID compliance.
I know plenty of companies making millions of dollars of revenue per month off their MyISAM table database products. Hard to do that with /dev/null I assume.
It works fine depending on what you are doing. Granted, there are typically better options these days, but this goes back 15+ years of silliness. Many (most?) web apps are write once, read millions.
For high volume/low value data that doesn't need perfect accuracy or consistency you can make MySQL/MariaDB absolutely fly.
That said, I hear PSQL can get close these days turning some knobs as well.
But, the ACID argument is tired and usually made in places where it simply is irrelevant. Most apps simply don't matter if they drop some data here and there, but developers act like they are building critical banking systems for their ad viewing platform. This is probably a top 10 favorite bike shedding topic I've seen in dev meetings over my career. In 90% or better cases you could have chosen literally any RDBMS and been fine, the arguments about it taking more time than the choice made will ever save.
Agree the disk format is much nicer with MyIsam, but don't you have a much greater chance of corruption in the case of a power failure? InnoDB has some annoying shortcomings, but in return it seems nice that you get your data consistency.
Depends on your definition of "much greater chance of corruption".
I have yet to see a single instance of this happening. And I have been running a bunch of servers for decades, each serving complex web applications to hundreds of thousands of users.
> On 19 September 2025, workloads running Azure Database for MariaDB will be deleted and associated application data will be lost.
This is the most insane part to me. Not only will they not support it, they're going to delete all of your data!