| Facebook doesn't use MySQL as a dumb k/v store. This is simply incorrect. 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.