- The two questions every buyer asks, whether there is a benchmark and how many TPS VoltDB can do, are both harder to answer honestly than they sound, because TPC-style benchmarks were built for the disk-based, lock-based designs VoltDB was built to eliminate.
- A transaction is not a fixed unit: a single-row primary-key lookup and a stored procedure that deduplicates, aggregates and updates materialized views over 5M+ rows both count as one, while K-factor, command logging and table size all shift throughput and latency.
- Across four real proof-of-concept workloads (telco mediation, 5G online charging, ML inference for autonomous networks, and VWAP), VoltDB delivered between 7,000 and 9,300 TPS per active vCPU without high availability.
- With k-factor=1 for full redundancy and zero-downtime failover, the range is 3,500 to 6,250 TPS per vCPU counting replica cores, with p99 latency under 5 ms for charging and mediation and under 10 ms for VWAP.
- Do not compare marketing TPS numbers: define your exact workload, infrastructure constraints and SLAs, then have each vendor run a PoC under identical conditions.
TL;DR
Why “how many transactions per second?” is the wrong first question, and what real-world PoC data tells us about VoltDB performance across telco, financial services, and autonomous network workloads
The Two Questions Everyone Asks
As a presales engineer at Volt Active Data, I hear the same two questions in almost every customer conversation:
- “Do you have a benchmark we can look at?”
- “How many TPS can VoltDB do?”
Both questions are completely reasonable. Both are also surprisingly tricky to answer well.
The Benchmark Problem
The most widely recognized database benchmarks, such as TPC-C, were designed in an era of spinning disks, row-level locking, and single-node architectures. They measure how well a database handles contention on a small number of hot rows with traditional lock-based concurrency control. That is exactly what VoltDB was designed to eliminate.
VoltDB uses a shared-nothing, partitioned architecture with serial execution per partition. There are no locks, no latches, no write-ahead logs in the traditional sense. Running TPC-C on VoltDB is a bit like testing a Formula 1 car on a cobblestone track. It will still be fast, but you are not measuring what makes it special.
Well-known benchmarks like TPC-C were designed for traditional disk-based databases with lock-based concurrency. They do not reflect the workload patterns where NewSQL databases like VoltDB deliver their strongest performance: high-throughput, low-latency streaming decisions on partitioned data.
The TPS Problem
“How many TPS?” sounds like a simple metric. It is not. In VoltDB, and in most SQL databases, one transaction can be fundamentally different from another:
- A simple
SELECTof a single row by primary key? Extremely fast. - An
UPDATEof one row? Also fast. - A stored procedure that deduplicates incoming events, runs aggregations, updates multiple materialized views, and operates on tables with 5M+ rows? That is a very different transaction.
On top of the transaction complexity, there are infrastructure and configuration factors that directly affect throughput and latency:
Factors That Affect VoltDB Performance
| Factor | Impact | Why It Matters |
|---|---|---|
| K-factor (HA) | Adds replicas per partition | K-factor=2 means 2 nodes can fail and the system keeps running, but every write is replicated to 2 additional copies, adding latency |
| Command Logging | Durability overhead | Ensures recoverability after a full cluster failure; adds disk I/O to the write path |
| VoltDB Topics | Avoids extra Kafka round-trips | Using internal topics to deliver results to consumers avoids the latency of an external Kafka hop |
| Transaction complexity | CPU time per operation | More SQL statements, larger tables, more joins = more time per transaction |
| Table sizes | Scan and index cost | Operating on tables with millions of rows is slower than tables with thousands |
| TPS vs. latency priority | Batching trade-offs | Tuning for maximum TPS often increases p99 latency; tuning for low latency may reduce peak TPS |
So when someone asks “how many TPS?”, the honest answer is: it depends on what the transaction does, how resilient the deployment needs to be, and whether you optimize for throughput or latency.
I decided to go through my recent PoCs and demos and try to extract a practical answer: what is VoltDB’s common speed per vCPU across multiple, realistic scenarios?
The Scenarios
Below are four real-world scenarios drawn from recent proof-of-concept engagements and benchmarks. Each represents a different workload profile, different infrastructure configuration, and different performance priorities.
Scenario 1
Mediation
Telco BSS/OSS | Event Processing | Deduplication & Enrichment
Mediation is the process that sits between network elements and downstream BSS/OSS systems in a telecom operator’s stack. Raw usage events, such as Call Detail Records (CDRs), data session records, and SMS logs, are generated by network equipment at massive scale. Before these records can be used for billing, fraud detection, or analytics, they need to be processed through the mediation layer.
The mediation pipeline typically involves:
- Collection – ingesting raw events from multiple network sources (switches, gateways, probes)
- Validation and deduplication – filtering malformed records and eliminating duplicates using event IDs or composite keys
- Normalization – converting records from vendor-specific formats into a unified schema
- Enrichment – looking up subscriber details, rate plans, and service profiles to augment the raw event with business context
- Aggregation – combining partial records (e.g., multiple segments of a single call) into complete usage events
- Routing – directing processed records to billing, fraud, analytics, or archival systems
The challenge with mediation is that it requires both high throughput (millions of events per second during peak hours) and strict correctness (every event must be processed exactly once, and duplicates must be reliably detected). Traditional mediation platforms use batch processing with file-based workflows, introducing minutes or hours of delay. VoltDB enables real-time mediation by processing each event as it arrives, with ACID guarantees on deduplication and enrichment lookups.
K-factor = 1
Command Log
VoltDB Topics
Dedup + Enrichment + Aggregation
5M+ subscriber table
~5K
TPS per vCPU (incl. HA)
< 5 ms
p99 Latency
48 vCPUs
Total Cores (24 active + 24 replica)
~240K
Total TPS
This is a complex transaction: each event triggers dedup checks against a rolling window, enrichment lookups against a 5M+ row subscriber table, partial record aggregation, and materialized view updates. The ~5K TPS/vCPU already includes the replica cores in the count, reflecting the true hardware cost of a fully redundant deployment.
The cost of zero downtime: With k-factor=1, every active partition has a full replica on a separate node. If any node fails, the cluster continues operating with zero data loss and no downtime. The 48 vCPU count includes both active and replica cores, because those replica cores are real hardware that must be provisioned.
Scenario 2
Online Charging (5G OCS)
Telco BSS | ACID Transactions | Quota & Balance Management
The online charging function is an ideal candidate for understanding the performance demands of 5G. Solutions must handle not only the load of connections from billions of new devices, but also the complexity of enforcing different policies for the increasing diversity of devices. Online charging in 5G networks must scale both with load and functional complexity without compromising on consistency or performance.
This benchmark, based on the published VoltDB telco charging application, simulates a simplified online charging system where each transaction:
- Allocates quota to a subscriber, verifying sufficient balance across 4 tables with full ACID guarantees
- Adds new users and adjusts balances, joining data from multiple tables
- Runs conditional logic within Java stored procedures to achieve maximum work per round-trip
The benchmark was tested on Google Cloud across cluster sizes from 3 to 27 nodes, on both 4-core and 16-core machines.
K-factor = 0 and 1
No Command Log
Multi-table ACID transactions
500K users per core
~7K
TPS per vCPU (k=0)
~3.5K
TPS per vCPU (k=1, incl. HA)
< 5 ms
p99 Latency
3.2M
Peak TPS (27×16-core)
The key finding: VoltDB demonstrates near-linear horizontal scaling. The throughput per vCPU remains remarkably consistent whether the cluster has 3 nodes or 27, and whether the machines have 4 or 16 cores. The 27-node cluster with 16 cores per node achieved over 3.2 million operations per second with p99 latency under 5ms.
With k-factor=1, the per-vCPU number drops to ~3.5K because you must provision replica nodes that mirror every active partition. The throughput per active core stays the same, but the total hardware footprint for the database doubles (streaming components scale separately). That is the real cost of full redundancy: not slower transactions, but more machines to guarantee zero downtime when a node fails.
Scenario 3
Autonomous Network (ML Inference)
Telco Core Network | ML Decisioning | Self-Healing Infrastructure
This scenario addresses autonomous network operations: ingesting real-time monitoring data from core network equipment, running ML model inference on each event, and deciding corrective actions for the network to self-heal, all within a single streaming pipeline.
The architecture uses the full VoltDB streaming stack:
- Kafka as the ingest source for network telemetry events
- VoltSP (Volt Stream Processor) for event validation and normalization
- VoltDB stored procedures for stateful ML inference and action decisioning
- VoltDB Topics to deliver decisions back to consumers without an extra Kafka hop
The workload processes events from 5 million network endpoints, with each event carrying 300-350 bytes of telemetry payload. The ML model runs inside VoltDB using VoltSP’s inline inference capabilities.
K-factor = 0 and 1
VoltDB Topics
VoltSP (ML Inference)
5M endpoints
300-350B per event
~9.3K
TPS per vCPU (k=0)
~4.5K
TPS per vCPU (k=1, incl. HA)
~73 ms
avg E2E Latency (k=0)
280K
Total TPS (k=0)
With k-factor=0 (no HA replication), the system achieved 280K TPS on 30 VoltDB cores across 3 pods, with end-to-end latency averaging 73ms (this includes the full pipeline: Kafka ingestion, VoltSP processing, ML inference, stored procedure execution, and result delivery via VoltDB Topics).
With k-factor=1, the per-vCPU metric drops to ~4.5K when counting all cores including replicas. The throughput per active core stays nearly the same, but the total hardware for the database doubles (streaming components like VoltSP scale separately). This is the price of full redundancy: if any VoltDB node fails, the cluster continues processing without interruption, with zero data loss and no manual intervention.
Scenario 4
VWAP (Volume Weighted Average Price)
Capital Markets | Financial Calculations | ACID Precision
This is not a telco use case, but it is an ideal scenario for VoltDB due to the fragile nature of financial ACID computations where precision and consistency are non-negotiable.
VWAP (Volume Weighted Average Price) is one of the most commonly used benchmarks in algorithmic trading. It calculates the average price of a security weighted by trading volume over a specific time period. Every trade execution needs to update running VWAP calculations in real-time with absolute consistency, as even a small rounding error or missed update can result in incorrect pricing and real financial loss.
The VoltDB implementation processes streaming market data events, each of which triggers:
- Price and volume validation
- Running VWAP recalculation with full decimal precision
- Materialized view updates for multiple aggregation windows
- ACID-guaranteed state updates across partitioned tables
K-factor = 1
Command Log disabled
ACID financial calculations
Materialized views
Streaming market data
~6.25K
TPS per vCPU (incl. HA)
< 10 ms
p99 Latency
48 vCPUs
Total Cores (3 VMs x 16 SPH)
300K
Total TPS
This PoC was run with k-factor=1 on 3 VMs (c2d-highcpu-32) with 16 sites per host, giving 48 total VoltDB vCPUs including replicas. The ~6.25K TPS/vCPU reflects the computational weight of maintaining running VWAP calculations with full decimal precision across multiple aggregation windows on every single trade event, while also carrying the cost of full HA replication. The sub-10ms latency reflects VoltDB’s strength in financial workloads where consistent low latency matters more than raw throughput.
Putting It Together
Here is the consolidated view across all four scenarios:
TPS per vCPU Across Scenarios
k=1 numbers include replica cores in the denominator. Replica cores actively process transactions to stay in sync with the primary partitions, so they consume real compute resources and must be provisioned for zero-downtime failover.
Summary Comparison Table
| Scenario | TPS/vCPU (k=0) | TPS/vCPU (k=1, incl. HA) | p99 Latency | Complexity | Key Characteristics |
|---|---|---|---|---|---|
| ML Inference | ~9.3K | ~4.5K | ~73 ms E2E | Medium | Full pipeline: Kafka, VoltSP, ML model, Topics |
| Charging | ~7K | ~3.5K | < 5 ms | High | Multi-table ACID, balance checks, quota allocation |
| Mediation | – | ~5K | < 5 ms | High | Dedup, enrichment, aggregation, 5M+ row tables |
| VWAP | – | ~6.25K | < 10 ms | High | Financial precision, materialized views, 48 vCPUs (3×16 SPH) |
The practical range: Without HA, VoltDB delivers between 7,000 and 9,300 TPS per active vCPU. With k-factor=1 (full redundancy, zero-downtime failover), the range is 3,500 to 6,250 TPS per total vCPU because replica cores must be counted as real infrastructure cost. The variation across scenarios is driven by transaction complexity, table sizes, and pipeline depth. The ~50% drop from k=0 to k=1 is the price of guaranteeing that no node failure causes data loss or service interruption.
So How Do You Actually Compare?
The honest conclusion is this: comparing database solutions from a buyer’s perspective is inherently difficult. Every vendor can produce impressive benchmark numbers under conditions optimized for their architecture. Published benchmarks are useful for directional understanding, but they rarely reflect your specific workload, data model, infrastructure constraints, and SLA requirements.
The factors that matter in your evaluation may be very different from the factors that matter in someone else’s:
- Do you need k-factor=2 for regulatory compliance, or is k-factor=0 acceptable for your use case?
- Is your priority maximum TPS or minimum p99 latency?
- How complex are your transactions? Simple key-value lookups or multi-step business logic?
- How large are your state tables? Thousands of rows or millions?
- Do you need end-to-end streaming with Kafka integration, or direct API calls?
The best approach for a meaningful comparison is:
- Define your exact workload – schema, transaction logic, data volumes, concurrency patterns
- Specify your infrastructure constraints – cloud provider, instance types, HA requirements, network topology
- Set your SLAs – target latency percentiles, minimum throughput, availability requirements
- Send these conditions to each vendor and ask them to demonstrate their solution under your specific scenario
- Compare apples to apples – same workload, same hardware, same SLAs
The bottom line: Do not compare marketing TPS numbers. Compare results from your own PoC scenario, run under your own conditions. That is the only benchmark that matters for your decision. We are happy to run exactly that with you.
Want to benchmark VoltDB on your workload?
Let’s define your scenario together and run a PoC that reflects your actual production requirements.
About Author
Featured Resources
