Based on a cursory glance at the properties of ACID, it seems like something that the financial world, especially the stock exchanges, have had to deal with when dealing with transactions.
I wonder if a similar architecture could be used for building a distributed database that could rival what was lost with foundation.
Financial services companies have three different issues:
* Banks don't do multi-record SQL (see Brewer's article on the topic)
* They don't do many transactions
* Nobody got fired for buying oracle or DB2
An oracle replacement won't be built for financial services companies.
ActorDB is a distributed SQL database with ACID transactions http://www.actordb.com/ and open source. Unlike FoundationDB SQL is a fundamental component and not an addon.
Oh, we will build it, I have no doubt. There's a demand, so I'm sure in 5 years Apache will have some project that quenches our thirst.
The key with transactions is that they make life easy for the client. AP systems are easy for database engineers to write (and yet they still manage to screw them up :P), but systems that support ACID constraints are easy for application developers to use. That's why FoundationDB was so special; they promised the best of both worlds; the horizontal scaling of traditional NoSQL systems, with the ease of use (w.r.t. reasoning about concurrency) of SQL/ACID systems.
I wonder if a similar architecture could be used for building a distributed database that could rival what was lost with foundation.