Skip directly to content


ACID: How to screw it up!

Thursday, February 25, 2016

In my previous post, I described four applications (three implemented, one an example) that require, or at least strongly benefit from, strong ACID transactions. With that out of the way, we can now get to the fun bits. 


Today’s claim: most databases that claim to be 100% ACID compliant fudge definitions, goof up, or deliberately mislead. This applies to 30-year old giants as well as strapping upstarts; it’s just a fact of life in databases.


I could make a giant chart with all of the products that claim to be ACID, and list where they fail.

Apps that need ACID

Thursday, February 18, 2016

There’s a lot of discussion about the value of consistency and ACID transactions in data management. I thought it would be useful to describe three fully implemented enterprise-class applications, and one example application, that need ACID transactions. These descriptions should make an abstract concept a bit more concrete.


“The Last Dollar Problem”

Airpush is a digital ad tech company. They came to us with their application that matches ad campaigns to advertising opportunities. One of the biggest challenges faced by ad tech companies is matching ad budget and ad spend.

Disambiguating ACID and CAP

Thursday, October 22, 2015

The ACID properties and the CAP theorem are two important concepts in data management and distributed systems. It's unfortunate that in both acronyms the "C" stands for "Consistency," but actually means completely different things. What follows is a primer on the two concepts and an explanation of the differences between the two "C"s.


What is ACID?

The idea of transactions, their semantics and guarantees, evolved with data management itself. As computers became more powerful, they were tasked with managing more data. Eventually, multiple users shared data on a machine.

Don’t Accept Data Loss when Upgrading to In-memory Database Performance

Tuesday, May 20, 2014

Data loss is the enemy of businesses everywhere. Snapshots, replication, active-active architectures, even physical measures such as backup generators are used to ensure data is preserved as it enters and is used or warehoused by the enterprise. Most companies use a database to manage this data and extract intelligence from it; therefore, the database has an important role in preservation of data – durability in database-speak.


As data wends its way through ingestion, transactions and analysis, many databases rely on frequent writes to disk to ensure data is durable, even in the event of

Intro to VoltDB Command Logging

Tuesday, July 26, 2011

VoltDB’s new command logging feature reduces the window of data loss during a cluster wide failure from single digit minutes (the window between snapshots) to zero. Command logging can be tuned to give you the same amazing latency and throughput you get from VoltDB, even on a single 7.2k SATA disk. Our unique approach to log based durability exploits the determinism and replication inherent in VoltDB’s architecture to avoid the overhead and latency of ARIES style logging.

How We Log

A command log is kept at every node and contains partially ordered stored procedure invocations.

Lies, Damned Lies and “Eventual Consistency”

Thursday, July 21, 2016

Let me start by making an arrogant statement:


There is no such thing as eventual consistency. There is only ‘Immediate Consistency’ and ‘Wrong’.


A lot of people would regard me as being unreasonable, but from my perspective I have a chain of reasoning that I don’t think you can fault:

  1. The purpose of any database is to hold data so someone (or something) can read it. They may not read it directly – it might be part of a total, for example. Or they might indirectly read it – you can check uniqueness by attempting to insert a key, knowing that a failure means we’ve seen this key before.
  2. Eventual

NoSQL vs. NewSQL: Choosing the right tool

Thursday, April 9, 2015

Trying to choose a database to solve a problem (or a whole set of them)? Here's a quick rundown of the advantages - and disadvatages - of NoSQL versus NewSQL. Choosing the right tool for the job at hand is 80 percent of getting to a solution; the other 20 percent is really understanding the problem you're trying to solve.


I'll start by pointing out that the term NoSQL is about as descriptive as categorizing unicycles and wheelbarrows as "NoTwoWheels". In truth, NoSQL is a broad category collecting disparate technologies beneath an ambiguous umbrella.

VoltDB Command Logging Replay

Wednesday, August 10, 2011

In the previous blog post, Ariel Weisberg described how VoltDB’s command logging feature works. He also briefly mentioned how we replay command logs during the recovery process. In this post, I am going to focus on the replay process and discuss how VoltDB recovers from catastrophic events.

Goals of Command Logging Replay

The goals of command logging replay are pretty simple:

  1. Ensure that the recovered database is 100% accurate to the last usable transaction in the command log
  2. Complete the recovery process in the shortest possible time

Command logging obviously adds important new functionality to

VoltDB inks deal with Flipkart, India’s largest online marketplace

Tuesday, October 20, 2015

When you believe in the product or service you’re selling, magic happens. For VoltDB, the latest bit of magic is being selected by Flipkart, India's largest online marketplace. Flipkart chose VoltDB, an in-memory SQL database, to horizontally scale its real-time order management system, a multi-tier architecture designed to handle scale and ACID transactionality in different tiers. With VoltDB, the new architecture will provide a unified relational view of the data from a single platform.


Flipkart offers more than 30 million products across 70+ different categories.

VoltDB’s New Command Logging Feature

Tuesday, July 19, 2011

We, at VoltDB, are excited to tell you about the command logging feature that we’ve been working on this summer. We’ve built this feature because our customers asked for it, and they’ve given us some great feedback on how it should work. Here’s a heads up to get you thinking about how you can make use of this new functionality.


So what’s command logging and why are we so excited about it? First, let me remind you of VoltDB’s snapshot functionality. A database snapshot is exactly what it sounds like — a point-in-time copy of the database contents written to disk.

What? VoltDB Stored Procedures?

Thursday, July 1, 2010

VoltDB is a relational store that uses SQL for its query language and stored procedures for its transactional unit of work. Clients invoke stored procedures to access the database. Stored procedures access data using parametrized SQL statements and can manipulate intermediate results in Java. Each stored procedure invocation is a transaction. A procedure’s data manipulations are atomic and isolated from other concurrently executing procedures.


Here’s a simple example, excerpted from the Voter sample application shipped with the VoltDB distribution kit.