Facebook doesn’t use MySQL as a dumb k/v store. This is simply incorrect. Although for primary product data (status upda
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 :)