Skip directly to content


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 WAN Replication in VoltDB

Monday, November 14, 2011

This is the first in a series of posts about WAN replication, a VoltDB feature that’s currently under development.  It provides a high level overview of our direction. More detailed posts will follow as we progress through our engineering iterations.


As an in-memory transactional DBMS, VoltDB delivers breakthrough performance and scale.  Two of the product’s most significant innovations, however, are in database availability and durability:

  • Availability – VoltDB delivers high availability (HA) via a synchronous multi-master feature called K-safety.

To Flash or Not to Flash: That is the Question

Tuesday, June 12, 2012

Written by Mike Stonebraker


I am often asked about the value of flash memory in OLTP database applications.  This blog post discusses flash technology in this context.  First, I discuss the future of flash in general; then I turn to flash (and other future storage technologies) in the context of a main memory DBMS, such as VoltDB.

The Future of Flash

Flash memory is clearly a “moving window”, since its price and performance are changing quickly. Historically, flash could only be written a few thousand times, before it would “wear out” and have to be replaced.

VoltDB 2.0 Features Summary

Wednesday, September 21, 2011

VoltDB 2.0 was released last week and I wanted to take this opportunity to summarize the important new features, including enhancements for database durability and recovery; key performance and interoperability improvements; and many enhancements geared at helping developers use VoltDB productively. Here are the details:

  • Durability and recovery. Version 2.0 introduces a new feature called Command Logging that allows VoltDB databases to be fully recoverable in the face of severe failures caused by hardware and software crashes.

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 WAN Replication – Pre-release Users Invited

Thursday, January 26, 2012

The subject of my last blog post was an introduction to VoltDB Replication, one of the major product additions that we’ve been working on. Well, with this post, I’m happy to announce that we’ve recently pre-released VoltDB Replication to selected users to perform beta-level validation!


VoltDB WAN replication involves duplicating the contents of one database cluster (known as the master) to another database cluster (known as the replica). The process of retrieving completed transactions from the master and applying them to the replica is managed by a separate process called the Disaster