Cloud bills have turned total cost of ownership into an architecture question. ARM-based instances such as AWS Graviton, Azure Cobalt, and Google Axion are priced below comparable x86 instances, but a data platform on ARM is only as viable as its vendor makes it. Many mission-critical platforms still run only on x86 or treat ARM as an afterthought. When the platform dictates the hardware, cost per transaction climbs, energy budgets overrun, and tail latency, the response time of the slowest 1% of requests, spikes under load. The vendor, not the team running the workload, ends up choosing the instances.
Full enterprise features on ARM, no application changes
Volt on ARM removes that trade-off. Native 64-bit ARM builds of the Volt server and Kubernetes operator carry the full enterprise feature set, including K-safety, which keeps redundant copies of every partition on separate nodes, along with command logging, snapshots, Active(N) cross-data-center replication, and in-service software upgrade. Existing applications run on ARM unmodified. In Volt’s own benchmark of a 400,000 TPS charging workload, AWS Graviton delivered roughly 40% more work per core than a comparable Intel instance at the same 10 ms 99th-percentile latency target, and the cost of supporting that workload came in around a third lower.
Why hyperthreading works against Volt and ARM doesn’t
Volt pins each data partition to a single CPU core and runs every transaction to completion, so it gains nothing from hyperthreading, where one physical core presents itself as two hardware threads. On hyperthreaded x86 instances, those two threads start contending for the core once utilization passes roughly 50%, and in the benchmark, p99 latency deteriorated sharply at exactly that point. On Graviton, every vCPU is a physical core, and latency held steady as load rose. Volt treats AArch64, the 64-bit ARM architecture, as a first-class target rather than emulating it, and rewrote the performance-sensitive code originally written in x86 assembly for ARM. Every release now ships native server, operator, and container builds for both architectures from the same release train.
Who it’s for
For platform and infrastructure teams running charging, policy, or fraud systems against a hard p99 budget, the payoff is usable capacity. Clusters can run hotter before tail latency moves, fewer or smaller instances handle the same workload, and teams pick hardware on price and availability instead of on what the platform supports. SQL, stored procedures, client libraries, Helm charts, and operational procedures all stay the same, so moving to ARM is an instance-type decision at deployment time, not a migration. See how the same workload compares on x86 and ARM.