Mmm... they were just doing shared-data distributed MVCC. Nothing new there. My takeaway from spending some time with the documentation that their SQL layer was a hack.
Well if it truly mattered out there right now there is a company that has a void that they need filling and all they have to do is speak up and help fund a replacement.
If you want those same features, consider VoltDB. It makes different tradeoffs on what kinds of ops are fast, but has all of those features.
Essentially arbitrary two-key transactions are slower. Partition-friendly writes and global reads are faster. Global reads with real SQL can be orders of magnitude faster.
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.
