> yet you propose dumbing down the database even farther, without any hope of ACID
> compliance, without any transactional integrity, indeed, without even really being > relational ? > at least, thats what I get from my first read of it. OK so you are a theorist/perfectionist, I can respect that. Perhaps what I meant to say instead of "dumbing down the database" was "dumbing down the use of SQL to the point where it is not much better that indexed-style reads and writes". Is my idea perfect? No, far from it, and if there are better ideas out there then great, I hope they get pushed forward. But I do believe my idea is far better than the alternative of sticking our heads in the sand and hoping that cloud computing goes away and in the mean time web developers are stuck using databases that only support very "dumbed down" SQL sub-sets/derivatives like Google's GQL or Amazon's SimpleDB query syntax. At a detailed level (which is NOT the direction I want this thread to go) I do not agree with your statement that my proposal has no "hope of ACID compliance or transactional integrity". When the "slices" are stored back to the cloud, this is the equivalent of a commit and the integrity thereof is as good as what ever the underlying technology is. Is the concurrency as good as native Postgres? Of course not. Is the commit/rollback flexibility as good as native Postgres? Again no. But what's the alternative? Watch cloud computing take off leaving Postgres with the reputation of "great database software in yesterday's era of monolithic servers"?
