Why Uber Engineering Switched from Postgres to MySQL
&gt; MySQL supports multiple different replication modes:<p>&gt; Statement-based replication replicates logical SQL statements (e.g., it would literally replicate literal statements such as: UPDATE users SET birth_year=770 WHERE id = 4)<p>Postgres has that too (using a 3rd party tool, but it&#x27;s an officially supported tool).  We were using it on reddit 10 years ago.  It caused a lot of problems.  I wouldn&#x27;t call that an advantage for Mysql.<p>Honestly, reading this it seems like the summary is: &quot;We don&#x27;t follow great engineering practices so we need a database more forgiving&quot;.  Which is fine if that&#x27;s how you want to run your business, but isn&#x27;t really the death knell for Postgres.<p>A specific example:<p>&gt; This problem might not be apparent to application developers writing code that obscures where transactions start and end. For instance, say a developer has some code that has to email a receipt to a user. Depending on how it’s written, the code may implicitly have a database transaction that’s held open until after the email finishes sending. While it’s always bad form to let your code hold open database transactions while performing unrelated blocking I&#x2F;O, the reality is that most engineers are not database experts and may not always understand this problem, especially when using an ORM that obscures low-level details like open transactions.<p>Your developer should understand database transactions.  But you should make it easier for them by abstracting it so that they don&#x27;t have to.  And in this particular case, I&#x27;d say they shouldn&#x27;t be using the database to do locking around sending a receipt.  It should be put into a queue and that queue should be processed separately, which avoids the transaction problem altogether.