-Edited 5/2/13 by Henning Diedrich to correct configuration typos.

Running on a suitable EC2 configuration (see details below), with our new VoltDB Erlang driver we achieved 877,519 transactions per second.

I am Henning Diedrich [1], CEO of Eonblast Corporation[2] a games company. I would like to introduce the new Erlang VoltDB driver we created, a piece of software that allows two genre-defining technologies to work together: VoltDB [3] and Erlang [4].

The Driver

I first came to VoltDB on the hunt for a better database for heavy duty online-game servers. I experienced first hand [5] what a … Read more

This is part 2 (of 2) of my Programming VoltDB – Easy, Flexible and Ultra-fast series. Blog post, part 1, showed how to build a VoltDB application using ad hoc queries and achieving thousands of transactions a second. It also showed how converting that logic to use VoltDB stored procedures allowed you to parallelize query execution and achieve 100,000+ transactions a second on a single node. In this blog post I’ll talk about scaling beyond 100,000 transactions per second by creating a VoltDB clustered database.

There are primarily two reasons why you would want to run VoltDB as a … Read more

We’ve recently put up a series of blog posts describing the components of a Spring-MVC web application, including VoltDB as the database, that saves votes being called in for talent show contestants. Today I’ll talk about what happened when we benchmarked the Voter application on Amazon’s cloud platform.  The short story – running on a suitable EC2 configuration (see details below), we achieved 686,000 TPS for a Spring-enabled application using VoltDB.

The Benchmark Application

I’ll start by summarizing the aforementioned blog posts, but you are welcome to read them:

Using the Spring @Schedule Annotation, Using the Spring Converter API … Read more

Hi, I’m Henning Diedrich, co-founder and CEO of Eonblast, Inc. I’m a guest contributor to VoltDB’s blog.

In February I was contacted by VoltDB about conducting a benchmarking project.  The company had recently released an updated version of a Node.js client driver that had originally been authored by Jacob Wright, one of VoltDB’s community members.  When I began looking into Node.js, it became clear that its architecture and scaling goals are quite well aligned with VoltDB’s, so I was intrigued by the idea of running a benchmark to see what the combined technologies could produce.  Like all languages and libraries, … Read more

VoltDB is very scalable; it should scale to 120 partitions, 39 servers, and 1.6 million complex transactions per second at over 300 CPU cores…

and

…scaling a synchronously replicated, active-active master, fully ACID, always-consistent database to a 40-server cluster is impressive.

A few notes:

As Baron says, these benchmarks were based on our “Voter” example. We ship this example with our distribution … Read more

Yesterday’s press release documented a 30 node SGI Rackable Cluster running VoltDB achieving 3.4 million transactions per second (at 10ms latency) running the “Voter” application.

Impressive numbers, indeed. And the numbers are even more interesting when you understand the transactions. Each Voter transaction consists of: 2 selects 1 insert (table with an index) 2 updates (materialized views, each with an index) Therefore, the SGI Cluster was performing 17 million SQL statements per second!

Tim Callaghan
Sr. Technical Consultant
VoltDB… Read more

It seems like I’ve been programming forever (we’re talking TS-1000, TRS-80, and Commodore64). I’ve always been looking to improve the performance of my programs, especially database applications. Better performance can usually be attributed to one of the following:

• New Hardware – [insert name of favorite hardware vendor] has just released new server technology that incorporates improved [RAM | CPU | Disk | RAID Controller]. At some point we’d purchase one of the new servers, install the OS and RDBMS software, restore a large database for benchmarking, and run scripts to test the performance. Performance always improved but it was never

… Read more

Point 1: Demonstrate SQL can be fast. Say what you want about our numbers and benchmark, but the language used to manipulate data was SQL and it clearly wasn’t bottlenecking VoltDB performance. We wanted to show the assumption that dropping SQL is a precondition for performance and scalability is false.

Point 2: VoltDB competes well on simple workloads like the key-value puts and gets, as well as complex workloads like our TPC-C like benchmark.

How … Read more

Edit on 6/2/10: Check out the follow up Benchmarking FAQ blog post with links to code.

The NoSQL movement was born of the need to scale data management with predicable cost. My subjective summary of the NoSQL credo: provide simpler core functionality, scale horizontally, leverage redundancy, expect and handle failures. These systems became known as NoSQL because SQL and schema was often given up for flexibility and simplicity. The name came about even though SQL was never the primary complaint; scalability was.

VoltDB was born to solve similar problems. Provide horizontal scalability at a cost per transaction that anyone … Read more