Which engine does your workload actually need?

VoltDB, VoltSP + VoltDB, or something else entirely. Answer a few questions about latency, state, and scale — we'll route you to a straight answer, including the one where Volt isn't it.

≤ 7 questions · two minutes · no email gate · retrace any answer

The three shapes of a Volt system

Most workloads that belong on Volt land in one of these. The guide above just asks the questions we'd ask you on a call.

VoltDB

The decision engine

An in-memory, partitioned SQL engine that executes each decision as an ACID transaction next to the data — single-digit milliseconds at hundreds of thousands of events per second.

Every event needs a verdict: approve, block, charge, route
Decisions read and update hot shared state — balances, quotas, sessions
Being wrong or slow costs real money

VoltSP

The stream engine

High-throughput stream pipelines — ingest from Kafka and friends, filter, enrich, window, and deliver — declared in YAML with Java when you need it, built for the fast path.

Data must move and change shape between systems, continuously
Freshness is measured in milliseconds, not minutes
Logic is per-stream, not per-account bookkeeping

VoltSP + VoltDB

The closed loop

Pipelines shape the torrent; the decision engine holds the state and issues the verdicts. Detect → decide → act in milliseconds, end to end, on one platform.

Streams need reshaping and events need exact, stateful decisions
The system must act on its own conclusions automatically
5G automation, fraud interdiction, real-time policy control

✓ This guide will also tell you when Volt is the wrong tool — batch analytics, modest CRUD backends, and pure topic-mirroring are better served by other stacks. We'd rather you build the right thing and come back when the fast path finds you.