Why Uber Switched from PostgreSQL to MySQL – A Critical Technical Review

Uber recently published an article titled “Why Uber Engineers Replaced PostgreSQL with MySQL?” which the author of this commentary argues is poorly framed and overly specific to Uber’s workload. The writer stresses that the article should have been titled “PostgreSQL limitations under heavy update scenarios” rather than a blanket criticism of PostgreSQL.

Update Operations

Uber claims PostgreSQL must update all indexes when a row is modified, while MySQL/InnoDB only updates the indexes of the changed columns. In reality, PostgreSQL’s HOT (Heap‑Only‑Tuple) feature can avoid index updates when the new row version stays on the same page, provided the update does not modify indexed columns. HOT can be tuned via the fillfactor setting. Uber’s engineers apparently did not consider HOT because their workload involved frequent updates that touched at least one indexed column.

Select Queries

The Uber article notes that InnoDB uses clustered indexes, which can cause an extra secondary‑index lookup compared to PostgreSQL’s single lookup. The commentator points out that this disadvantage only matters if many queries rely on secondary indexes; otherwise most accesses are via primary‑key lookups, making the impact negligible.

Additionally, Uber omitted PostgreSQL’s limitations with index‑only scans, especially for tables with frequent updates. PostgreSQL’s support for index‑only scans was limited before version 9.2 and remains less useful for highly mutable data.

Index Rebalancing

Uber mentions that B‑tree indexes require periodic rebalancing, implying heavy disk movement. The commentary clarifies that rebalancing occurs only during index modifications (splits, merges) and does not involve massive data migration. Node splits happen roughly every 100 inserts, and root splits are rare (about once per billion inserts). In practice, most indexes stay shallow (≤5 levels), so rebalancing overhead is modest.

Physical Replication Issues

Uber experienced a replication bug in PostgreSQL 9.2 that corrupted downstream data when a node split was not correctly replicated. The bug caused large portions of the index tree to become inaccessible. Uber also faced other replication challenges: high replication traffic, write amplification from updates, and long downtimes when upgrading PostgreSQL.

Two mitigation strategies are mentioned: (1) configuring a timeout to delay applying replication streams, allowing read transactions to finish; (2) having replicas send feedback to the primary so it does not discard needed row versions. Uber reportedly used only the first method.

Developer Practices and Organizational Impact

The author laments that many developers lack deep database knowledge, often opening long‑running transactions for unrelated tasks (e.g., sending emails). This ignorance can exacerbate the perceived shortcomings of PostgreSQL in Uber’s environment.

From an organizational perspective, hiring more developers tends to average out skill levels, making it harder to rely on deep database expertise. The commentary suggests either hiring top talent (difficult) or hiring average developers and providing extensive training, which consumes time—a scarce resource for fast‑growing companies.

Conclusion

The commentator believes Uber does not need to replace PostgreSQL wholesale; instead, they could adopt a custom solution that mirrors MySQL/InnoDB’s strengths for their specific use case. The original Uber article, however, paints PostgreSQL in an unfairly negative light and should not be used as a generic guide for database selection.