Mark Callaghan puts out a great explanation of why pitching new databases to large MySQL users will almost always fail:
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.
I can still see some good reasons why a new database “vendor” should continue to try to get big users to take a look at their product:
it’s the only way to learn:
- what’s unique for these users
- what’s at the top of their concerns, and
- how they address them
While you won’t be able to make them switch, if your product addresses their issues, it will
be prepared for the next big user.
2. there’re still chances for smaller, greenfield, internal projects to start using your product
It’s common sense to build a product using the tools you are already familiar with — it helps reducing the risks and also cutting down the time to market . What happens though is that there are always people that don’t follow this rule starting new products using tools that are they are not that familiar with. There’re also products that grow faster than the team’s know-how evolves. These are just two quick examples where a new product that has learned from big users can help.
Original title and link: Why are you using MySQL?