MariaDB is a drop-in replacement for stock MySQL. It's performance is actually better than MySQL.
https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibi...
https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibi...
When I ran the tests for MariaDB 10.x and MySQL CE 5.6.x the advantage even went further for MySQL with around 20% better performance.
I find always funny how with every release you can get opposing claims from each camp regarding performance.
I'm sure one day MariaDB will replace stock MySQL but clearly it's not ready yet.
btw Oracle is doing a good job with MySQL atm.
One concrete example is hashjoins, a fairly simple and efficient strategy for many general purpose workloads: MariaDB supports hashing as a join strategy since 5.3/5.5 [1] back in 2011. MySQL, to the best of my knowledge, still lacks any implementation of this. OracleDB, of course, supports hash joins. Oracle has every incentive not to implement hash joins in MySQL because hash joins are one of the performance features that they use to drive sales of OracleDB.
[1] https://mariadb.com/kb/en/mariadb/what-is-mariadb-53/#join-o...
Obvious troll is obvious.
> the performance is BS
We're extremely happy with our "BS" performance.
MySQL professional here. I'm quite pleased with Oracle's 5.5 and 5.6 releases, and feel that they're doing a pretty good job. While they've not been perfect stewards, I feel they have done better than Sun -- perhaps you don't remember the fiasco that was the 5.1 release?
I don't feel that this is a trollish opinion. Mark Callaghan, a MySQL luminary who has done a lot of excellent work for the community also has positive things[0] to say about Oracle's stewardship of MySQL.
Actually yes, it is. It doesn't work the other way around (for example timestamp column has a different description, so dump cannot be loaded into MySQL). But you can use MariaDB in place of MySQL and there should be no performance degradation, since they come from the same codebase.
Reliability was mentioned too - in that case Oracle actually failed by holding back tests. In MariaDB you can reproduce testing if you want. In MySQL not anymore.
MariaDB is also impacted by the lack of tests, they are absolutely not making replacements for all those tests, and they continue to pull code from upstream. So, same problem there.
The fact that they continue to "pull" some code is because they're not idiots, and aren't going to duplicate effort. As far as I'm aware, they are now being very selective about what they pull.
Calling Oracle an "upstream" is a joke. They aren't publishing atomic changesets, which also means the Oracle fork of MySQL is no longer a morally Open Source software program.
MariaDB is NOT impacted by some vaporous lack of tests. They are building tests for every change they're making. As for the tests privately held by Oracle, well, those tests don't help anyone because they're not public and don't enjoy public scrutiny. Who knows if they're even running them?
They have received large investments from companies like Intel, and have been granted extensive engineering (and probably financial) help from companies like Google and Facebook. Probably many others. And they have most of the MySQL brains-trust in their employ, Monty most famously. I don't know how anyone could argue they're under-resourced for the task of maintaining and improving a mature product.
Compare that with Oracle, who pulls dangerous stunts like this: http://ronaldbradford.com/blog/when-is-a-crashing-mysql-bug-...
You mean Jeremy Cole, the guy you're arguing with, who led the effort at Google to standardize on MariaDB[0], who worked for many years with Monty at MySQL AB and who is a recognized leader in the MySQL community?[1] Fuck that guy, I have no idea how he could have such an opinion.
[0]: http://www.theregister.co.uk/2013/09/12/google_mariadb_mysql...
[1]: http://openlife.cc/blogs/2013/april/mysql-community-awards-2...
I know for a fact that if we were forced away from MariaDB back to stock Oracle MySQL releases, we'd have to expand onto more slaves and fix queries that are no longer optimized.