Latest MySQL release is underwhelming, say some DB experts The latest release of MySQL has underwhelmed some commentators who fear Oracle — the custodian of the open source database — may have other priorities. Earlier this month, Oracle — which has long marketed its range of proprietary database systems — published the 9.0 version as an "Innovation Release" of MySQL. MySQL 9.0 is now …
MySQL is simply "Oracle Lite"* , a way for Oracle to entice enterprises with some cash to trade in their FOSS kit in favour of a "proper" RDBMS as Oracle would see it. Don't fall for it, you're way better off investing into PostgreSQL. I have no real beef with MySQL or Maria but something about Postrges that just makes it feel like a solid system when you use it.
* as a 25 years veteran DBA, I know there was a product called "Oracle Lite" many moons ago, used to run on Palm Pilot if I remember correctly.
Is there any reason to choose MySQL or MariaDB over PostgreSQL these days?
Previously, PostgreSQL offered better features, MySQL had better performance and a feature-set that was good enough for many use-cases.
Now, PostgreSQL is faster and offers better features. So even if you don't need the additional features, you still get the performance benefits, and you might grow into the additional feature-set later.
For new projects PostgreSQL is the obvious choice. More features, better performance, excellent community and consultant support.
The problem is existing systems where people have used misfeatures in MySQL. Then the best you can do is switch to MariaDB and hope the company behind it stays in business.
I'm currently porting a set of applications from MariaDB to PostgreSQL. Things like case insensitivity in MariaDB and my predecessors' love of the SET column type are the biggest issues.
I'd quibble the assertion that MySQL offered better performance: it certainly offered better write performance but did this largely by not being ACID compliant, which can quickly cost a lot more. But schema changes and many queries led to table-locks and absolutely dreadful performance. To be fair, MySQL was never designed to be a relational system and did what it was supposed to well. The real problems started when people tried to use MySQL where a real RDBMS would have made more sense. This has helped engender a generation of poor systems and practices around a fundamental misunderstanding of how relations work.
If you need to support a MySQL based application you install MariaDB.
If you want a feature-rich SQL server for a new project then PostgreSQL becomes a valid option depending on the skill sets you have access to.
The choice becomes harder if you are designing around the need for high-availability replication - at this point, you hire an expert for either PostgresSQL or MariaDB and forget about MySQL.
If i was developing an application from scratch then PostgreSQL would be my go to choice, but sometimes you are using an existing application which has been built around LAMP stack with MariaDB / MySQL, and unless you have the time and knowledge to strip out any dependency on MySQL/Maria you have no choice other than to use one of them.
I mean for most, myself included for at least the past 5 maybe 6+ years "mysql" has meant MariaDB. I haven't formally used the "official" MySQL from Oracle I don't know maybe a decade now? Prior to MariaDB the org I was with used Percona MySQL 5.5 (with Percona support, the Percona build had some of their own custom enhancements). It was only after Percona's costs went ballistic one year(up something like 800% YoY for an unlimited site support license which we probably had opened one ticket in the previous year) that we cancelled support, and a new DBA pushed us towards MariaDB.
I've never been a formal DBA, though I have used and managed "MySQL" off and on for about 20 years now(including replication, backups, Galera clusters, and custom monitoring), first production stuff I recall being I think on top of Red Hat Enterprise 2.1, or maybe 3.0. I have also been a shotgun DBA (with focus mainly on operations not things like queries/schema/etc) for Oracle for a few years too. I'll never forget the arguments I had with my manager back in 2007 regarding latch contention and bad application design while he and others were trying to blame Oracle for the outages.
I've dabbled a BIT in Postgres over the past year for a couple of different small apps, I don't doubt it's a fine DB, but wow it is such a PITA to work with operationally after using MySQL for so long(such as create a new DB, create a user/pass, grant access to the DB over the network etc for me today that's many web searches and trial & error). Even Oracle DB seems more friendly in some respects. But hey as long as there is someone else to manage the DB I don't really care, just ask them to figure it out. My job isn't DBA at the end of the day.
I don't doubt if Postgres in the orgs I work with picked up and I actually used it more frequently I'd become more used to it and wouldn't be so bad. But you could also say the same thing about other tools, like Chef configuration management which still annoys me significantly after 12 years of using it on a semi regular basis.
Uncle Larry killed Solaris and Sun the same way, he wanted bits and pieces and so he bought them all, took what he wanted then let the rest wither away into nothingness.
It is Uncle Larry's way.
Well, that and coming up with ludicrous and usurious methods of exploiting his softwares large installed base to take even more cash from the companies suckered into using it.
MySQL's feature being gated behind a paywall is precisely why it can not be considered a true open source database. There are features available only in MySQL Enterprise edition that have long existed in MariaDB. For example: "The MySQL Thread Pool is an alternative and optional thread handling mechanism that is available in the MySQL Enterprise Edition."
The addition of the vector datatype in the community edition is a laughable feature, syntactic sugar at best and does not offer any meaningful benefits to the end user. Without indexing support, a table with vector data is nothing more than a flat file. The key feature that is required is the indexing, which already is implemented in HeatWave, only as a cloud service.
At MariaDB we've done precisely the opposite and have worked (together with the community!) at implementing the core functionality of Vector Search. A preview is coming out soon (by the end of the month). It will all be available as open source, part of the next MariaDB LTS. MariaDB Vector working on any modern CPU will prove that there is no need for specialized hardware or other dedicated cloud instances to be able to take advantage of AI together with a database.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
