I strongly rebut the following claim, which is central to the article:<p>"Internet commenters, in their infinite wisdom, were quick to point out that if you’re dealing with money, you had better use an ACID database. But there was a major flaw in their argument. Most so-called ACID databases — for example Postgres, MySQL, Oracle or MS SQL Server — would not have prevented this race condition in their default configuration."<p>I hesitate because I don't really understand the details of the situation the exchange faced. But, going by the linked references here:<p><a href="https://bitcointalk.org/index.php?topic=499580" rel="nofollow">https://bitcointalk.org/index.php?topic=499580</a>
<a href="http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_roughly_100_btc_from_an_exchange_and/" rel="nofollow">http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_...</a><p>it appears that the pattern in question, if translated very unnaturally to SQL, is something like:<p><pre><code> CREATE TABLE account(id int8, balance numeric);
...
BEGIN;
SELECT balance FROM account WHERE id = 123;
-- application sees 100, subtracts 90, sees that
-- it's still positive and does:
UPDATE account SET balance = 10 WHERE id = 123;
COMMIT;
</code></pre>
Technically speaking, running that in postgres in the default configuration (read committed) is prone to a race, and you'd need to use repeatable read or serializable mode to protect you.<p>But that's ridiculous. Anyone using SQL would instead do:<p><pre><code> CREATE TABLE account(id int8, balance numeric, check(balance >= 0));
...
UPDATE account SET balance = balance - 90 WHERE id = 123;
</code></pre>
And that is <i>not</i> prone to a race. Try it in any version of postgres, in any configuration. You can't get double withdrawls (where only one takes effect), and you can't get it to go below zero.<p>So, the author is <i>technically</i> right: (a) if you translate the NoSQL-isms into SQL in an unnatural way; <i>and</i> (b) don't bother to use SERIALIZABLE mode, which costs very little in most situations.<p>I agree with the author that isolation is tricky, and developers should not be expected to understand the nuances. And I applaud the development of a testing framework to really understand the various kinds of isolation and how they apply to different products. But the example is a bad one, because it actually does work just fine in postgres, and probably many other systems.