wippler.dev
PostgreSQL is terrible
Why Uber Engineering Switched from Postgres to MySQL We encountered many Postgres limitations: Inefficient architecture for writes, Inefficient data replication, Issues with table corruption, Poor replica MVCC support, Difficulty upgrading to newer releases … Postgres does not have true replica MVCC support. The fact that replicas apply WAL updates results in them having a copy of on-disk data identical to the master at any given point in time. This design poses a problem for Uber. Oxide Podcast: The challenges of operating PostgreSQL at scale during their time at Joyent and how autovacuum caused an outage starts at about 20 minutes into the podcast. (This podcast was the inspiration for this blog post) “We found a lot of behavior around synchronous replication that was either undocumented, or poorly documented and not widely understood, which contributed to a feeling that this thing (PostgreSQL) was really hard to operationalize. Even if you know about these things, they are very hard to workaround, and fix.”
Related Pain Points6件
No In-Place Major Version Upgrades
8PostgreSQL does not support in-place major version upgrades. Upgrades require either dumping and restoring the entire dataset or setting up logical replication, with rigorous application compatibility testing required. Delaying upgrades increases complexity and risk, as outdated versions miss critical security patches, transforming routine maintenance into a complex, high-risk migration project.
Table corruption issues in PostgreSQL
8PostgreSQL experiences table corruption problems that can result in data integrity issues. This was significant enough to motivate organizations like Uber to evaluate alternative databases.
Complex configuration and monitoring required for replication and high availability
7Managing PostgreSQL replication requires intricate configuration and careful monitoring to prevent data loss or corruption. Achieving high availability demands automated failover mechanisms, load balancing between primary and standby servers, and selecting the appropriate replication strategy.
Inefficient write architecture compared to other databases
7PostgreSQL has an inefficient architecture for write operations compared to alternatives like MySQL. This limitation was significant enough for organizations like Uber to switch database systems.
Complex and error-prone autovacuum configuration
6Configuring autovacuum correctly is challenging due to its complexity. Default global settings are inappropriate for large tables with millions/billions of tuples. If autovacuum invocations take too long or are blocked, dead tuples accumulate and statistics become stale, causing gradual query slowdown. Manual intervention is often required.
Replicas lack true MVCC support
6PostgreSQL replicas apply WAL updates, making replicas identical copies of the master at any point in time. They don't have true replica MVCC support, preventing queries from reading different versions of data on replicas compared to the primary. This design poses significant constraints for distributed systems.