High Availability
The Galera cluster addon, either through codership directly, Percona XtraDB Cluster, or built into MariaDB I really think is the differentiating factor here. The fact you can run this reliably over low latency WAN environments in multi-master is nothing short of amazing. No need to try to choose a primary, and when that fails promote a secondary, then deal with rejoining/syncing the failed primary. It also allows for ACID compliance. When you look at solutions for PostgreSQL, a lot seem to rely on external scripts or proxies that are held together with duct tape and bubble gum ... and nothing supports ACID compliance unless it is an Active/Passive setup.
Maybe PostgreSQL is amazing on the query language side, performance and reliability, and sure, a simple deployment is probably just as easy between MySQL and PostgreSQL, however deployment for high availability, that is way more complex (and inferior).
Then there is the client API which is woefully inadequate. There are simple things that some other DBMS's support or aren't braindead about:
* Multiple row binding to a prepared statement (bulk inserts! ... yeah yeah, you can do comma delimited insert values, but you then hit the max # of bound parameters really quick)
* Client Side prepared statement handles (you have to manually declare a prepared statement and deallocate it when you no longer need it)
* Defining row fetching size for large reports (until 9.2 PQsetSingleRowMode() didn't even exist, you had to wait for the full result set before processing)
* Fetching column types from the server relies on you knowing the integer id of the datatype OID from the source code of the server (src/include/catalog/pg_type.h) as it isn't exposed in the client side api for some reason.
* Fetching column lengths from the server, you have to know that things like VARCHAR they add an additional 4 bytes to the length returned, so its not a usable length but an internal storage size which is useless to an integrator.
* There's probably more that I can't think of off the top of my head, but it was one of the more frustrating DB backend driver's I've written. (Granted, its not the only one with bugs, Microsoft has a long outstanding crash in their driver -- happens to be I hit the same as https://www.easysoft.com/support/kb/kb00808.html Issue #2)
I haven't dived into the server-side code, but if the client-side is any indication, it gives me concerns.
We've run with 100M rows no problem, but proper indexes are extremely important with MySQL, and if you didn't have the forethought up-front of creating the right indexes for you exact usecase (which of course can change over time), forget about creating new indexes, its basically impossible without a long outage window (Granted, I'm still on MySQL 5.7, maybe they've made this non-blocking in MariaDB).
Biting the hand that feeds IT
