What Is VoltDB?

What Is VoltDB?

VoltDB is a NewSQL database designed for online transaction processing (OLTP). NewSQL describes systems that keep the SQL interface and ACID guarantees of traditional relational databases while pursuing the horizontal scalability usually associated with NoSQL. In that spirit, VoltDB keeps the active data set distributed across a cluster and held in memory, rather than mostly on disk like classic engines.

The system prioritizes executing short, well-defined transactions at very high rates. Instead of long analytical scans (OLAP), it targets flows that expect sub-millisecond responses, such as payment authorization, telecom charging, fraud checks, or ad auctions. The relational model, primary keys, indexes, and SQL queries are all supported, so the data model feels familiar to SQL developers.

A Brief History and the NewSQL Context

VoltDB traces its roots to the H-Store academic research project led by database researcher Michael Stonebraker and colleagues. H-Store questioned the locking, buffer management, and logging overhead that traditional disk-based engines pay for OLTP, and instead argued for an in-memory, single-threaded, partitioned design. Those ideas were later commercialized as the VoltDB product.

VoltDB is widely regarded as an early and representative example of the NewSQL approach. In later years the product and company were rebranded as Volt Active Data, though the community and literature still frequently refer to it as "VoltDB." If you are curious about other distributed SQL systems that share a similar philosophy, see our articles on Google Cloud Spanner and OceanBase.

Architecture: In-Memory and Shared-Nothing

VoltDB uses a shared-nothing cluster architecture. Each node manages only its own slice of the data; nodes do not share a common disk or memory pool. Because active data lives mainly in RAM, the latency of disk access is largely removed from the hot path.

The most distinctive design choice is that each partition executes transactions serially on a single thread. Since only one transaction runs in a partition at a time, the row locks and latches that become expensive under high concurrency in traditional engines are no longer needed. Transactions start and finish quickly instead of waiting on locks. This is a well-known way to reach high throughput; in return, developers are expected to partition the workload cleanly.

Serial, deterministic execution also matters for replication and recovery: when the same transaction invocations run in the same order, every replica produces the same result. This property underpins the command logging and K-safety mechanisms discussed below.

Partitioning and the Data Model

VoltDB treats tables in two ways. Partitioned tables are split across the cluster by a chosen partition column (for example, a customer ID); each row lives in exactly one partition. Replicated tables suit small, rarely changing reference data and are copied to every partition, so joins against them can be performed locally.

Transactions fall into the same split. Single-partition transactions touch data in only one partition and deliver the highest performance. Multi-partition transactions require coordinating across partitions; they remain correct and consistent, but carry additional coordination cost. A good schema keeps frequent queries on the single-partition path as much as possible.

• Choose the partition column to match the natural access key of your most frequent transactions (e.g. account ID, user ID).
• Make small, seldom-changing reference tables replicated.
• Keep multi-partition transactions off the hot path unless they are truly necessary.
• Plan capacity so the entire active data set fits in the cluster's aggregate memory.

Stored Procedures and the Transaction Model

In VoltDB the primary unit of a transaction is the stored procedure. A single stored-procedure call is treated as one transaction: it either applies fully or not at all (atomicity). Procedures are typically written in Java and run parameterized SQL statements inside; ad-hoc SQL can also be executed directly for simpler cases.

The advantage of this model is that transaction logic runs close to the data (server side), reducing network round trips. Because of the determinism rule, a stored procedure's output should depend only on its inputs; random values or uncontrolled side effects are discouraged, since they can break consistency across replicas.

Example: Table Definition and Partitioning

Below is a simple relational schema with a partitioning declaration. The PARTITION TABLE statement specifies which column a table is partitioned on.

-- Accounts table, partitioned by account id
CREATE TABLE accounts (
  account_id BIGINT       NOT NULL,
  full_name  VARCHAR(128) NOT NULL,
  balance    DECIMAL      NOT NULL,
  PRIMARY KEY (account_id)
);

PARTITION TABLE accounts ON COLUMN account_id;

-- Small reference table is copied to every partition
CREATE TABLE currencies (
  code VARCHAR(3)  NOT NULL,
  name VARCHAR(64) NOT NULL,
  PRIMARY KEY (code)
);
-- (no partition declaration => replicated)

A single-partition update receives the partition key (account_id) at call time and runs directly in the relevant partition:

-- Example: SQL updating a single account's balance
UPDATE accounts
   SET balance = balance - 100
 WHERE account_id = 42;

Durability: Command Logging and Snapshots

The biggest question for any in-memory system is how data survives a power loss or node failure. VoltDB addresses this with two mechanisms. Snapshots write a consistent copy of the data set at a point in time to disk. Command logging records not the changed rows, but the transaction invocations that were executed.

Logging invocations rather than rows is possible because of deterministic execution: during recovery, the latest snapshot is loaded, then the logged invocations are replayed in the same order to bring the system back to its last consistent state. This approach aims to keep the logging cost on the write path low.

High Availability: K-safety and Replication

For high availability, VoltDB offers a replication model called K-safety. The K value specifies how many extra copies of each partition are kept in the cluster; K=1 tolerates the loss of one node, and higher K values tolerate multiple simultaneous losses. Thanks to deterministic execution, each copy stays in sync by processing the same invocations.

For disaster-recovery scenarios, enterprise capabilities such as cross-datacenter replication may also be available. Because the scope of such features can vary by version and license, it is best to rely on the current product documentation.

Comparing VoltDB with Other Approaches

The table below compares VoltDB with traditional disk-based relational databases and typical key-value NoSQL systems in broad strokes. The goal is not to crown one system, but to clarify which job suits which tool.

To recall how classic relational engines work, our Oracle Database article helps; for another example of an in-memory relational approach, see Oracle TimesTen. For column-oriented in-memory analytics, our SAP HANA article offers useful contrast.

Typical Use Cases

VoltDB shines where data is "in the moment" and decisions must be made within milliseconds:

• Telecom: real-time charging, quota, and session control
• Finance: payment authorization, risk and limit checks
• Fraud detection: evaluating rules and scores at the moment of a transaction
• Ad tech: real-time bidding and budget tracking
• IoT and telemetry: high-volume event ingestion and instant aggregation
• Gaming and digital services: leaderboards and virtual-economy transactions

The common thread is that the workload can be partitioned by a natural key (account, user, device) and the transactions are small and well defined. When these conditions hold, the single-threaded, partitioned model shows its throughput.

Strengths and Limitations

When Should You Consider VoltDB?

VoltDB becomes a strong candidate when your workload is dominated by short transactions, your latency budget is tight, and your data partitions cleanly along a natural key. Conversely, if complex reporting and wide analytical scans dominate, or if the data set is too large to fit in memory, a disk-based relational engine or an analytical system may be a better fit.

Rather than locking onto a single product, it is healthier to define your workload first. To see the different database families side by side and which one fits which job, our Database Types Guide is a good starting point.

Frequently Asked Questions

Does VoltDB keep all data in memory?

The active data set is held mainly in memory, which is where the performance comes from. For durability, however, snapshots and the command log are written to disk. So it is not accurate to say "everything is lost in volatile memory"; disk is used for persistence and recovery.

What is the difference between VoltDB and Redis?

Both run in memory, but their purposes differ. Redis is mostly used as a key-value and data-structure store; VoltDB is a database offering full SQL, a relational schema, and multi-statement ACID transactions. When you need complex, consistent transactions, this distinction becomes decisive.

Is VoltDB open source?

Historically, an open-source community edition was offered alongside a commercial edition; however, because license terms and edition boundaries can change over time, you should rely on the official product documentation for current and binding information.

Summary

VoltDB is a NewSQL database that combines the relational model and ACID guarantees with an in-memory, shared-nothing, deterministic execution engine. Its single-threaded partition model, stored-procedure-centric transactions, and command-log-based durability optimize it for high-volume, low-latency OLTP. With the right workload and a solid partitioning design it delivers a clear advantage; it should not, however, be treated as the answer to every general-purpose scenario.