Trading durability for performance without NoSQL
Developers turn to NoSQL solutions whenever they are confronted with a DBMS (write) performance challenge. I think that in most of the cases that is an exceptionally bad idea. By choosing NoSQL you trade the A, C and I from ACID for performance: Atomicity (risk of writes half succeeding, due to lack of multi-entity transactions) Consistency (risk of ambiguous data due to denormalization into multiple key/value sets) Consistency (risk of “messy” data, due to lack of schema and constraints) Isolation (risk of parallel writes on inconsistent state, due to lack of multi-entity transactions) Durability (risk of losing data by not flushing to disk, but keeping in memory) A, C and I are actually the things of ACID that I often don’t want to trade. The thing I am most willing to trade is the “D”. I don’t care that in the very unlikely event of an application or server crash a few seconds of writes are lost in exchange for a ten to hundreds times better performance. Or as they say at MongoDB: ...