May 25, 2010

VoltDB finally launches

VoltDB is finally launching today. As is common for companies in sectors I write about, VoltDB — or just “Volt” — has discovered the virtues of embargoes that end 12:01 am. Let’s go straight to the technical highlights:

I should also note that when Tim Callaghan described architectural options to get around 2PC performance issues, they sounded a lot like eventual consistency. Maybe tunable RYW consistency isn’t in the cards, but at least there’s a NoSQL-like possibility with VoltDB.

VoltDB’s open source strategy is:

VoltDB had a beta test with about 150 participants. None is in production yet, although at least a few are clearly headed there. Most VoltDB beta testers are in some kind of online business, with a particular concentration in everybody’s new favorite market, online gaming. Most of the rest are in investment/trading — a major target market for at least three different Mike Stonebraker companies — and a few are in telecom. VoltDB assures me that some of the beta users are companies one actually has heard of before, but VoltDB is not in a position to name any of those.

VoltDB is not ideally suited for a classic order management system, since you’d want to partition both on CustomerID and SKU, the latter because you’d constantly updating inventory stock levels. However, this argument doesn’t apply in the case of virtual goods. Virtual goods that are sold for real money — and hence need ACID levels of transaction integrity — are thus a clear target market for VoltDB. (The example that came up was in, you guessed it, online gaming.) The other interesting use case that Tim highlighted was low-latency analytics/ELT. For reasons I didn’t totally grasp, Tim likes to call this “Stateful ELT.” (Given that the data goes into the VoltDB database before much else happens to it, I’m pretty sure I heard “ELT” correctly. But I guess I might have been mishearing “ETL”.)

VoltDB company highlights include:

Comments

16 Responses to “VoltDB finally launches”

  1. H2O Development Blog » VoltDB Launches on May 25th, 2010 5:32 am

    […] in some of the technical details of the commerical offering I’d recommend looking at Curt Monash’s summary on his DBMS2 blog. Categories: New Database Systems Tags: databases, in-memory Comments (0) Trackbacks (0) […]

  2. John Hugg on May 25th, 2010 7:25 am

    Hi Curt,

    Thanks for the post!

    VoltDB does in fact support SUM in SQL queries. We don’t suggest you SUM millions of values in a single query, as VoltDB is optimized for shorter, OLTP-focused transactions. However we offer some materialized view support to maintain a sum on a large table or on large “group by” clauses.

    -John Hugg
    VoltDB Engineering

  3. Federico Feroldi on May 25th, 2010 10:58 am

    What are the main architectural differences between VoltDB and Redis?

  4. Bill Karwin on May 25th, 2010 11:11 am

    @Federico Feroldi: Redis and VoltDB are both in-memory data stores, but Redis is a key/value store. Values can be strings, lists, sets, and ordered sets. So clearly non-relational.

    VoltDB describes itself as a relational DBMS with partial SQL support. To be relational, repeating groups (like lists and sets) are not allowed.

  5. Ashwin Jayaprakash on May 25th, 2010 4:47 pm

    Hopefully this will not fragment the community.

    We already have quite a few open source Java SQL/NoSQL/Semi-SQL systems 🙂 Multiple efforts like Hbase, Cassandra, Voldemort, Hive, Pig and the rest. Just hoping this will be different (in a good way).

  6. Michael Stonebraker, l’homme qui peut sauver le SGBD relationnel du NoSQL | www.LeGrandBI.com on May 26th, 2010 3:33 am

    […] propriétés ACID. Nous avons bien affaire là à une base transactionnelle. Curt Monash sur DBMS2 (VoltDB finally launches) souligne sur son blog quelques limitations quant à l’implémentation SQL de cette première […]

  7. Emanuele Pitcher on May 26th, 2010 4:19 pm

    VoltDB does in fact support SUM in SQL queries. We don’t suggest you SUM millions of values in a single query, as VoltDB is optimized for shorter, OLTP-focused transactions. However we offer some materialized view support to maintain a sum on a large table or on large “group by” clauses.
    +1

  8. Sriram Srinivasan on June 2nd, 2010 10:38 am

    I immensely liked the original paper arguing for the transaction-confined-to-core architecture (“The end of an architectural era: (it’s time for a complete rewrite”).

    This architecture gives me pause: queries have to be extremely partition conscious, otherwise they are working on possibly incomplete data. I’m sure I can get used to it, considering the performance benefits.

    However, the present incarnation of the db (v 1.0) is a complete non-starter purely for its failure behavior. A failed node cannot restart and automatically join its peers. The entire database and all clients have to be restarted. Are you kidding me?

  9. Jonah H. Harris on June 2nd, 2010 9:20 pm

    Hey Curt,

    I benchmarked one of our workloads at myYearbook against VoltDB and most definitely validated their performance claims as far as single-partition accesses go. Thankfully, a good amount of our data can easily be partitioned, so no schema redesign is really necessary. The main drawbacks I see are lack of driver support and some missing SQL features. While we’re not yet running VoltDB in production, it’s definitely a promising system that I can see being adopted by organizations that are developing new OLTP-oriented applications.

  10. John Hugg on June 3rd, 2010 5:14 pm

    Hi Jonah,

    Thanks for trying out VoltDB. We’re hard at work on future releases. If you want to let us know what driver support or SQL would be most helpful, please visit our forums and let us hear about your experiences: http://community.voltdb.com/forum.

  11. Details and analysis of the VoltDB argument | DBMS2 -- DataBase Management System Services on June 30th, 2010 10:37 am

    […] for VoltDB, for which the slide deck is happily available. It’s all nicely consistent with what I wrote about VoltDB last month, in connection with its […]

  12. Riptano, and Cassandra adoption | DBMS2 -- DataBase Management System Services on July 6th, 2010 11:18 am

    […] it for new projects. True, I’m hearing even less evidence that any one of Membase, Voldemort, VoltDB, Akiban, Clustrix, or Riak – for example – is setting the world on fire than I am for […]

  13. Some quick notes on HP-Vertica | DBMS 2 : DataBase Management System Services on February 14th, 2011 12:31 pm

    […] would make partial sense for HP to acquire VoltDB, and fold VoltDB into […]

  14. Notes and links October 22, 2010 : DBMS 2 : DataBase Management System Services on February 26th, 2012 6:57 am

    […] Holahan is now VP of Marketing at VoltDB, which is a lesson to me about giving free consulting … Anyhow, Fred tells me that VoltDB has […]

  15. I’m collecting data points on NoSQL and HVSP adoption | DBMS 2 : DataBase Management System Services on January 5th, 2013 8:53 am

    […] of May, VoltDB had one paying customer, plus 150 beta customers who weren’t in production […]

  16. So long, and thanks for all the help. | InsideMySQL on January 24th, 2015 3:21 am

    […] “greater-known but nonethemore smart” brother, Mark […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.