> I think if you introduce (multi-'row') ACID into any of today's NoSQL database, you'd just end up with a bad traditional database Strongly disagree, although

> I think if you introduce (multi-'row') ACID into any of today's NoSQL database, you'd just end up with a bad traditional database Strongly disagree, although there is truth to the converse (adding sharding to a traditional database yields a bad nosql implementation :). There's a sketch of how Google added multirow transactions to bigtable for app engine (via a layer above bigtable called megastore): http://perspectives.mvdirona.com/2008/07/10/GoogleMegastore.aspx http://perspectives.mvdirona.com/2008/07/10/GoogleMegastore.... The key idea is that "a per-entity-group transaction log is used. One of the rows that stores the entity group is the entity group’s root. The log is stored with the root, which is replicated like all rows in Big Table." This is basically a version of the approach advocated by Pat Helland in his paper on "Life Beyond Distributed Transactions" -- http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf -- namely, that the most sane approach to distributed transactions is to redefine the problem, and restrict transactions to be within "entities" that fit on a single machine. Which, as App Engine demonstrates, turns out to be enough to do an awful lot.