&gt;  I find MySQL to be both reliable and incredible durable i.e. it handles yanking the power cord quite well.<p>Mmm. Assuming that your underlying disks don&#x27;t lie, losing <i>only</i> the data that was in-flight to the WAL (or whatever is the equivalent in your DB of choice) is the absolute <i>worst</i> data loss you should see from a real SQL database in that situation. [0]<p>Think about the case where an error causes the DB software to crash... You really can&#x27;t make good data robustness guarantees if an unexpected crash endangers more than just the data that&#x27;s in-flight to the WAL.<p>I personally have had the disks that back a rather large (but relatively low-update-volume) Postgres DB drop out on <i>multiple</i> occasions and never lost any data at all. This shouldn&#x27;t be unexpected behavior. :)<p>&gt; You say &quot;upserting into a mysql table&quot;. Which storage engine? MyISAM? InnoDB?<p>&quot;In addition, an INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one unique or primary key is also marked as unsafe. (Bug #11765650, Bug #58637)&quot; [1]<p>Given that this is an <i>unqualified</i> assertion, straight from the MySQL docs, it seems safe to say that this is a weakness in MySQL&#x27;s UPSERT-alike, rather than any limitation of a particular underlying storage engine. (Here are some bug reports that <i>also</i> make unqualified statements about the behavior at issue: [2][3])<p>&gt; ...I was hoping someone could give me a compelling reason to switch to it or to use it.<p><i>shrug</i> Both MySQL and Postgres are capable databases. Postgresql has better documentation, appears to have substantially better internal architecture, and -from what I remember of my early days with MySQL- has <i>far</i> fewer hidden sharp edges than MySQL.<p>I&#x27;m not here to tell you to change what DB you&#x27;re currently using for your production stuff... I don&#x27;t think anyone is. For my projects, I <i>have</i> had substantially better experiences with Postgres than MySQL.<p>EDIT: It occurred to me in the shower that I didn&#x27;t make &quot;loss of in-flight WAL data&quot; sufficiently clear. Unless you <i>explicitly</i> ask for a mode where writes are acknowledged before the DB believes that they&#x27;re safe on disk, [4] then the only &quot;data loss&quot; in the scenarios I described in the comment would be data that had been transmitted <i>to</i> the server, but not acknowledged as committed to the DB. So, correctly-written client programs would experience this &quot;data loss&quot; <i>only</i> as a transaction that failed to commit, maybe followed by DB unavailability. Sorry for the ambiguity. :(<p>[0] <a href="http:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.4&#x2F;static&#x2F;wal-reliability.html" rel="nofollow">http:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.4&#x2F;static&#x2F;wal-reliability.ht...</a><p>[1] <a href="http:&#x2F;&#x2F;dev.mysql.com&#x2F;doc&#x2F;refman&#x2F;5.7&#x2F;en&#x2F;insert-on-duplicate.html" rel="nofollow">http:&#x2F;&#x2F;dev.mysql.com&#x2F;doc&#x2F;refman&#x2F;5.7&#x2F;en&#x2F;insert-on-duplicate.h...</a><p>[2] <a href="http:&#x2F;&#x2F;bugs.mysql.com&#x2F;bug.php?id=58637" rel="nofollow">http:&#x2F;&#x2F;bugs.mysql.com&#x2F;bug.php?id=58637</a><p>[3] <a href="http:&#x2F;&#x2F;bugs.mysql.com&#x2F;bug.php?id=72921" rel="nofollow">http:&#x2F;&#x2F;bugs.mysql.com&#x2F;bug.php?id=72921</a><p>[4] I say &quot;believes they&#x27;re safe&quot; because underlying storage can <i>always</i> lie, and there&#x27;s not a goddamn thing you can reliably do about it if it does.