Oracle has had this issue with PL/SQL since it was introduced.

Mike Stonebraker is the co-founder and CTO of VoltDB, which makes a novel on-line transaction processing (OLTP) relational database management system (RDBMS). He recently gave a talk entitled “VoltDB Decapitates Six SQL Urban Myths”. You can read the s…

VoltDB is clearly interested in “C”, but it’s not cleanly “CP” or “CA”. It will stay available in the face of many partitions/failures, but there are some scenarios where it will stop service if it can’t guarantee “C”.

That said, it’s our goal to make failures that stop service as avoidable as possible.

Everything you say makes complete sense to me, and I’m happy to hear that the general transactions work properly. That must have required a lot of good engineering! I’m glad to hear things are going so well.

Over time we will, as you say, be more careful with partition placement, and support clusters that span racks with lots of machines. This is actually particularly interesting in some of the public clouds available, as they don’t give you all the information you might like yet.

Still, we have yet to run into a use case that would need more than 20 nodes or so. We have no problem doing millions of multi-statement transactions per second on a cluster that size, and individual machines aren’t getting slower over time. One nice thing about being more than an order of magnitude faster is that you need many fewer machines.

Re transaction types: VoltDB asks the developer to classify transactions as either single-partition or multi-partition. We do support fully general transactions with multiple round trips, but they are of course, much slower. One thing we allow the developer to to is to tag a batch of SQL as the “final” batch for a transaction. This hint allows VoltDB to combine some cleanup work and can eliminate a round trip on the network. For a transaction with a single batch of SQL (one or more statements with no Java in between), this hint allows for the transaction to often complete in one round trip. These are the “one-shot” transactions we used to talk about.

Thanks for the well wishes. Things are good at VoltDB. Congrats on the Google purchase.

VoltDB also guarantees more than the “C” of the paper. Their “C” is only linearizability. VoltDB provides actual transactions, which provide linearizability but much more.

I have a question. VoltDB is based, at least to some degree, on H-Store. H-Store was a university prototype, of about two years ago. The H-Store paper that I read talked about three kinds of queries (“transaction classes”): single-sited, one-shot, and general. Is the one-shot concept in VoltDB? Does VoltDB do general transactions (even if they’re not recommended and don’t claim to be fast)?

Thanks! VoltDB so novel and cool! I hope everything is going great at VoltDB.

“Neither failure scenario is great, but for most apps, one scenario is much worse than the other. That’s why we believe there’s a place for both kinds of systems.”

In “violent agreement” on this.