subject text In order for the ACD of <a href=http://en.wikipedia.org/wiki/ACID>ACID</a> to be true on a non-clustered database, one typically needs: <ol> <li> a write ahead log <li> to sync the log to disk to make sure it's contents are on the disk before writing it's changes to the database file and to sync the database changes to disk before removing the corresponding log entries </ol> But a modern disk can only do a few dozen disk syncs a second, so if an ACID database vendor cites performance statistics of more than a few dozen individual sequential write transactions per second per disk then AFAICS there are three possibilities: <ol> <li> the small print says they are using some form of non-volatile write cache (hardware RAIDs and NetApps usually have these) <li> the small print says the transactions are not ACID - they only sync writes to the OS buffers <li> they're lying or don't understand the problem </ol> So if you're at a company that needs to do more than a few dozen ACID transactions per second and isn't using non-volatile write caches, you can and probably will lose important committed transactions since an OS crash or loss of power will mean the OS buffers are lost. <p> I learned this by writing my own small database (SkipDB) and doing it wrong the first time. I've since rewritten it and will be posting it soon. Thanks to <a href=http://www.xxeo.com/>Dru Nelson</a> for pointing out this general problem and the non-volatile cache solution. <p> A final note: There are other things that can go wrong, such as the disk not writing the data properly, a bit in memory being flipped by a cosmic ray, etc which only redundancy can solve. password