I think we have different definitions of maturity.
Mature to me is cleanly implemented and robust in execution.
Mature to you seems to be "released the longest", sometimes these are connected but I don't think this is true for this case.
Mature to me is cleanly implemented and robust in execution.
Mature to you seems to be "released the longest", sometimes these are connected but I don't think this is true for this case.
A lot of people like to bash MySQL, but without citing specific examples, or by referring to problems that haven't been true in a decade or more.
I've listed a large number of huge corporations that have had great success with MySQL, and have decided to stay on MySQL despite having the resources to migrate away if they saw a compelling reason. Some of the companies on that list are relatively new, yet still chose to start with MySQL, or migrate to MySQL after scaling.
If MySQL is as flawed as people in this thread insist, why are so many companies continuing to use it and even migrating to it? In a few cases I can provide a first-hand answer, and maturity and ecosystem are two of the biggest factors.
1) Why are large companies still using mysql: "We can deal with the pain", Facebook turning mysql into a dumb k/v store is not equivalent to using it's feature set. Nor is it a resounding recommendation.
2) Why are new companies using mysql: Everyone knows mysql, people don't know the problems they will have until it's either too late or MySQL performs decent enough for now.. Many people haven't even heard of PostgreSQL or think of it as foreign and strange and don't wish to reeducate.
People bash on MySQL because like PHP it's architecturally bad and things are being solved at a glacial pace, it's defaults are still absurd, it's handling of character types is absolutely insane unless you know precisely what you're doing and it's absolutely full of inconsistent and often counter-intuitive behaviour.
examples: error in constraint commits data anyway[0], just clobbering your database. UTF8 isn't actually UTF8 it's only three bytes wide, so you need utf8mb4[1].
[0] https://www.youtube.com/watch?v=emgJtr9tIME [1] http://dev.mysql.com/doc/refman/5.7/en/charset-unicode-sets....
Although for primary product data (status updates, friends, likes, etc) the access pattern is restricted via a data access layer, it's supporting a distributed graph model (nodes and edges, distributed across many shards). Far more features than a "dumb k/v store".
Separately, Facebook uses MySQL for countless other critical OLTP use-cases, and (for better or worse) even a few OLAP use-cases. It's the primary store of Facebook, across the entire company. It's the storage layer for ad serving, payments, async task persistence, internal tooling, many many other things. Most of these use-cases make full use of SQL and the relational model.
I was the lead dev on FB's internal DBaaS, which alone supports several thousand different workloads. Despite making up only a few percent of fb's mysql fleet, it alone is still larger than the vast majority of Postgres deployments on earth.
Regarding people not having heard of Postgres: these are big companies with smart, well-informed engineers. And I assure you that Uber and Lyft haven't moved from pg to mysql because they hadn't heard of pg :)
One of your examples is a 9-minute video, from a non-MySQL expert, about mysql 5.5 which came out 6 years ago.
Your other example is a perfectly valid "gotcha", but I don't know of any system that is completely free of gotchas. IMO, needing to know to type utf8mb4 instead of utf8, isn't a good reason to avoid a database altogether.
To reiterate, I am not arguing MySQL is perfect (far from it), or even "better" than pg. I was merely answering the GP's question of why MySQL became more widely-used. I don't wish to engage in yet another mysql-vs-pg endless debate, since my personal opinion is both systems are good choices in different situations.
Neither was it the other way round, when uber switch from mysql to pg. Both the directional changes appear to have much more to do with changes in engineering leadership, than anything else.
They then refused to ugprade postgres from 9.2 to newer version (and most of the stuff they complain about is not a problem in newer version) and moved to MySQL, used as append-only k/v store (they call Schemaless) now.