Why Uber Engineering Switched from Postgres to MySQL
I would argue that most of these Postgres "flaws" are actually advantages over MySQL when you look at them holistically rather than the very specific Uber use-case.<p>Postgres's MVCC is superior (can rollback DDL, can add indexes online, can have open read transactions for a VERY long time without impacting other parts of the system)<p>Postgres supports many types of indexes, not just b-tree.  One thing it doesn't have is clustered b-tree indexes... which is really what MySQL does that makes it somewhat "better."  I wonder how Uber adds an index to a table that already has 1B+ rows in it with mysql?<p>Postgres have WAL level replication is a better guarantee of actually replicating the data correctly.  I cannot tell you how many times I've had to tell my boss that the "mysql replicas might be slightly out of sync with the master" because of various replication issues.  The way it handles triggers and scheduled events alone is garbage and can very easily break replication and/or silently cause inconsistency.<p>As for data corruption, if there is a bug that causes corruption, then there is a bug.  I don't think that is a fundamental design flaw as implied in this article.  You shouldn't rely on 1/2 assed replication design to accidentally save you from the data corruption bug.  There are many downsides to the design MySQL has that are simply not listed here.<p>I have been both a professional MySQL administrator as well as Postgresql (as well as SQL Server and many NoSQL engines).  Many of these Postgres issues are only issues at crazy huge scale, and I would say at that point you probably want to move away from relational anyway.  MySQL has its own very large set of problems at scale as well.<p>It sounds like Uber is using MySQL as just a data bucket with primary keys ("Schemaless") which is good -- because you can't alter tables to save your life with MySQL.<p>At the end of the data each developer/business needs to use what works for them, but I would really shy away from pointing to this article as a linchpin in the "MySQL vs. Postgres" war (if there even is such a thing.)