Sysbench for MySQL 5.0, 5.1, 5.5, 5.6, 5.7 and 8
smalldatum.blogspot.com
smalldatum.blogspot.com
I wonder if that project has managed to continue progressing while MySql seems to have regressed.
It's super easy for all of us on HN to say "Oh look Oracle ruined another thing". But it would much more interesting to have quantified results to compare from.
I write these posts to document & market the problem and motivate upstream and my team to make things better. I don't think they are ruining MySQL.
I don't mean to further smear MySQL, just point out that this might not be a regression. It might be MySQL fixing bigger issues in default configurations. Spending 18% raw performance might be worth it.
It seems odd, though. I guess it's all PostgreSQL all the time for me, from now on.
Those blindly suggesting MariaDB or Percona is all well and good but naive. Percona generally follows MySQL upstream but makes their own little tweaks which could be (but are not always) fixed in MySQL upstream based on differing specific priorities.
MariaDB is highly diverged at this point and likely has a whole different set of problems and benefits.
Author of these posts is well known for a long (10+ years) history of working with MySQL at a deep level rivalling that of many of the developers, generally writes good stuff (though is not infallible :)
Even their own benchmarks show MySQL 5.7 dipping below previous versions at the low end of the concurrency scale.
I also showed the impact for IO-bound workloads, and even there the regression is larger than I want. But not as bad as the in-memory workloads.
If you're not using MySQL in the first place, why would you care?
However, for MySQL in an existing application, the migration costs might make it not worth it. There can be a number of pernicious gotchas that aren't obvious at first. MariaDB is more or less set-and-forget.
for the average medium to high traffic mysql install, i find 5.7 to be much faster than 5.6 or mariadb where concurrency and varying workloads prevail.
ymmv, do your own testing to see which db is a good platform for your specific workload. maybe it's mysql 5.6 maybe it's mariadb, maybe it's postgres.
for me mysql 5.7 brings much awaited niceness, saner defaults and even though not all workloads are better on it i think oracle is really trying to iterate. likely they will fix this regression and there would be little reason to use it over 5.6 or older.
Adding features without incurring performance penalties is probably hard to pull off. FWIW we're still talking about 10000 queries/sec.
One reason not to move to mariadb could be slight differences in schema syntax edge cases. But if you're starting from scratch, it doesn't matter.
Percona's fork is also much closer to vanilla (than MariaDB), so there shouldn't be any issues even for existing databases. Unless maybe if the system/cluster set up is very complex so there is additional cost for migration. For new projects though, I can't think of any reason to use vanilla over one of the forks.
If they have it, how can they miss this? Is it too specific?
If they haven't, did they throw it away after acquiring Sun? Or Sun never had it?
- MySQL/MariaDB are much better tested for almost every OSS web app and framework I use. It may be the only database that is official and thoroughly supported. If I want to interoperate on the same DB across many applications, MySQL/MariaDB is the lingua franca.
- It's fast enough. The vast majority of applications never need to scale beyond a few hundred requests per second. Any database on nearly any hardware with sufficient memory will do this.
- Aurora. Scale up automagically (not infinitely, but pretty easily) when you do find yourself with an app that needs to scale a lot and fast.
- It's fine. Sure, PostgreSQL does a number of things better (though I'd wager some of the reasons MySQL is getting slower for some workloads is because it is now doing some of the things PostgreSQL has done for a while, and they require more resources; features have a cost). If I were weighing out the pros and cons in isolation, I'd pick PostgreSQL. But, I'm not. I'm building things on top of other things, and those other things were built with MySQL. when MySQL was faster than PostgreSQL I didn't choose it because of its speed (I used to use PostgreSQL for my company website, but migrated to MySQL about ten years ago).
MySQL/MariaDB may not be better, but they're good enough. MySQL and PostgreSQL have converged in terms of features and performance to be reasonable substitutes for each other.
Is there CTEs in MySQL yet?
What about binary JSON and indexes on that?
How is implementing arrays and aggregate functions beyond simple arithmetic going?
Or maybe there is a way to write triggers in Python or JS if I want some performant number crunching with ACID guarantees?
Can DDL statements be rolled back, so I wouldn't have to pull my hair out during development after running migration I'm working on, if it happens to have a typo?
Everyone for whom MySQL is not enough just move to Postgres and most open source ORM's support both so it's mostly a non issue. At a job I was told we would use Postgres very very shortly before release. All I had to do is change configuration settings and run a command, and that was 5 years ago.