As an in-memory RDBMS, VoltDB competes directly against products like Oracle TimesTen and IBM's SolidDB. Comparatively, VoltDB's architecture is designed specifically to scale out on clusters of commodity servers (TimesTem and SolidDB are single-node datastores), giving Volt access to larger amounts of inexpensive main memory.

VoltDB also competes indirectly with NoSQL products like Cassandra, which achieve performance and scale primarily by sacrificing SQL and ACID transactions (Volt preserves both).

As an in-memory database, VoltDB offers durability through command logging and disaster recovery via a recently-introduced feature called database (WAN) replication.

Hope this helps.

I think durability should not be defined in terms of actual backing hardware. VoltDBs transactions commit and stay committed. If you restore from a backup, just like any other database, you'll have data loss until the backup point. What if my hard drive crashes when it loses power? At that point I'm in the same position as when I lose RAM.

VoltDB is often compared to other in-memory NoSQL systems, although I'm not aware of any that actually offer cross-server transactions. VoltDB is best when you have a high volume OLTP workload and need to really scale beyond what traditional RDBMS can do.

Edit: Here's a benchmark using VoltDB as a key-value store: http://voltdb.com/company/blog/key-value-benchmarking

> What if my hard drive crashes when it loses power? At that point I'm in the same position as when I lose RAM.

Oh sure, except that the probability of losing your hard drive when you lose power is about 1 in a very big number. Whereas, the probability of losing the contents of your RAM when you lose power is 100%.

Now, MySQL (and in fact, most RDBMS outfits) provide tools for fixing corrupt data. But you actually need corrupt data to fix. That's the entire point of a hard drive.

I'm sure VoltDB would be perfect for a chat application or something of that nature. It would be terrible for anything that involved the transfer of $$$ (banking, ecommerce, etc).

VoltDB Community Edition uses synchronous intra-cluster replication, as well as rolling on-disk snapshots for durability.

The Enterprise Edition adds a synchronous or asynchronous command log (a logical journal) as well as asynchronous multi-cluster replication.

The VoltDB blog has a series of posts covering command logging in detail: http://voltdb.com/company/blog/intro-voltdb-command-logging http://voltdb.com/company/blog/voltdb-command-logging-replay http://voltdb.com/company/blog/voltdb-command-logging-option...

In short, VoltDB offers tunable durability from single-node purely in-memory, all the way up to synchronous disk storage on multiple local nodes and multiple asynchronous copies in another data center. All options are fully transactional. All options are extremely performant.

We've worked very hard to make durability and performance not mutually exclusive. We have internally achieved six-figure TPS numbers using synchronous writes (requires a disk controller with a BBU, or a decent SSD).

I was making a more theoretical point that defining "durable" in terms of specific hardware isn't a very elegant definition.

In practice with VoltDB, you'll replicate to multiple machines synchronously (so you'd need to lose power to separate servers to lose data). VoltDB enterprise has command logging.

For a chat messages, I'm not sure VoltDB would be the _best_ choice, perf wise. Chat messages are usually more ephemeral - why go through the overhead of ACID for those?

For real $$$ transfers, you'll probably want synchronous WAN replication, to really ensure you never lose transactions.

VoltDB maintains a total perfect ordering to transactions as well.

Someone please correct me if I'm wrong, however I believe that VoltDB is highly tuned for a specific usage that benefits lots of small operations on large amounts of data. It is less beneficial, if not detrimental, for large operations on medium or large amounts of data.

You're entirely correct - VoltDB is very OLTP focused. Its predecessor, H-Store (decent paper here: http://www.vldb.org/pvldb/1/1454211.pdf ) ran on a single-thread-per-processor model that was very performant for short operations, but could obviously cause high latencies in the presence of long running operations. Presumably Volt runs on a similar model.

edit: ah, MichaelGG has explained it much better in another part of the comment thread!

Indeed, I'd never heard about it and found myself intrigued. After a bit of reading, it appears that VoltDB supports a very limited number of DDL and DML operations (essentially, you can create tables an views, and select, insert, update, and delete). There are a few basic aggregate functions like SUM and COUNT and no single-row functions. If you need to do anything at all complicated you're doing it in Java, or returning the results to the client program so it can do it.

VoltDB sound like a potentially great thing for an application that's really (and only) OLTP. But it's definitely not ready to replace Oracle, PostgreSQL, etc. for more general-purpose needs.