Why aren't you using X, version 2

Sometimes I get asked why am I not using product X where X is anything but MySQL. The products that are suggested change over time and the value of X very much depends on the person asking the question. An ex-manager from my days at Oracle told me that Oracle would be better and developers from the SQL Server team told me the same. For those keeping score there was a social network that ran SQL Server and they were kind of enough to explain why.

Too often this is an assertion rather than a question and it would be more clear to say "I think you should be using X". A better question would be "Why are you using MySQL". This is the burden we carry for running MySQL at scale, but I am not in search of sympathy. There are several possible answers.

Getting better with age

This might explain existing deployments:

1. It was there when we arrived
2. We made it better (along with Oracle, Percona, MariaDB, etc)

It is pretty good

With the quality of the 5.6 release and features likely to appear in 5.7, I expect MySQL to get many new deployments. This isn't just a legacy thing. MySQL performance is excellent for IO-bound workloads and almost excellent for in-memory. Manageability is about to get much better when GTID, parallel apply and enhanced semi-sync are deployed (or deployable). It isn't perfect. We need more features, PS usability is a work in progress and all of the replication goodness might not be there for most users until 5.7 is GA. 

Scalability

Sometimes I am told that something else scales better, but scalability is rarely defined. Context is very important here. If your deployment has a few servers then you want to minimize management overhead as the cost for people is larger than for hardware. But things change when a small team runs a huge number of servers and for that it is very important to minimize hardware cost by using a DBMS that is efficient for some of high QPS, IO-bound, read-heavy or write-heavy workloads. Note that a small team running a huge deployment is an existence proof that one or both of these are true -- the team is awesome, the product is manageable.

Leaving out quality of service, a simple definition for scalability is that a given workload requires A people, B hardware units and C lines of automation code. For something to scale better than MySQL it should reduce some of A, B and C. For many web-scale deployments the cost of C has mostly been paid and migrating to something new means a large cost for C. Note that B represents many potential bottlenecks. The value of B might be large to get more IOPs for IO-bound workloads with databases that are much bigger than RAM. It might be large to get more RAM to keep everything cached. Unfortunately, some deployments are not going to fully describe that context (some things are secret). The value of A is influenced by the features in C and the manageability features in the DBMS but most web-scale companies don't disclose the values of B and A.