In July 2016, Evan Klitzke, a staff engineer in Uber's core infrastructure group, published Why Uber Engineering Switched from Postgres to MySQL. It became one of the most argued-about database posts of the decade. Not because Uber moved databases, which companies do all the time, but because it explained why in terms of storage-engine internals: how rows sit on disk, what an index points at, and what a replica actually receives.
Read it today for the reasoning, not the verdict. The problems it describes are real and still worth knowing, the Postgres community answered parts of it within days, and Postgres itself changed in the years after. All three halves of that story are useful when you pick a database.
What they had
Uber started as a monolithic Python backend with Postgres for persistence. By 2016 it was moving towards microservices, and in many places where Postgres had been used, it was adopting Schemaless, its own sharding layer built on MySQL.
The post analyses Postgres 9.2, which Uber was running, and notes that its on-disk design hadn't changed much since 8.3. Replicas were fed by Postgres's built-in streaming replication, including across data centres on the West and East Coasts. The biggest replicas had 768 GB of memory, of which only about 25 GB was the database process itself; the rest was left to the operating system's page cache.