Uber: Choosing a Database for Write Amplification
also called Uber Postgres to MySQL
Uber publicly documented moving from Postgres to MySQL for their workload, and the reasoning is a useful lesson in evaluating a datastore against your actual access pattern.
The context
In 2016 Uber published an account of why they had moved a substantial workload from Postgres to MySQL. It was, and remains, contested — Postgres has evolved since, and several of the criticisms were disputed at the time. It is included here not to settle the argument but because the reasoning method is exemplary.
The reasoning
The concerns they described were all specific to their access pattern — a very high rate of updates to existing rows.
Write amplification. Because of how Postgres implements row versioning, an update writes a new row version, and every index on the table must be updated to point at it — even indexes on columns that did not change. On a table with many indexes and a high update rate, the physical write volume is a large multiple of the logical change.
Replication volume. Physical replication ships the changed bytes, so that amplification propagates to every replica and across the network to other regions.
Connection handling. A process per connection made very high connection counts expensive, which interacts badly with a large fleet of application instances.
Why this is a good case study
The lesson is not "MySQL is better". It is that the team identified the specific characteristic of their workload that interacted badly with the engine's design, measured it, and chose accordingly — then published the reasoning so it could be argued with.
That is what a technology selection should look like. The common failure is choosing on general reputation, benchmarks that do not resemble your workload, or team familiarity, and discovering the mismatch after the data is in.
The transferable lesson
Evaluate a datastore against your access pattern, not against its general reputation. The questions that matter: what is your read-to-write ratio; are writes inserts or updates to existing rows; how many indexes will the hot tables carry; what is the replication topology and how much data crosses it; how many connections will the application fleet hold at maximum scale.
And note the meta-point: this is a one-way door. The data model and datastore in a system with millions of records and many consumers is among the most expensive decisions to reverse, which is why it deserves the analysis that framework choices do not.