Throughput and latency are reported separately for Verify mode and Performance mode, on AWS instance storage and on local RAM-backed storage. All runs include the required sync calls and background checkpointing.
TPS counts completed business commands per second; K means thousand. Completion latency includes the wait for the final business result. A p99 of 2 ms means 99% of measured completions took no more than 2 ms.
What drives throughput
Batching is the main source of throughput: a batch groups many commands into one replicated log entry, so replication and disk-sync costs are shared across the batch. Batching is transparent to business logic: a handler is written for one command at a time and does not need to consider batches. Batch size does not affect business results. Each command still executes as its own transaction in the global order, so the same commands produce the same outcomes whether they are grouped in batches of 16 or 1,024. Other contributors are reuse of verified simulation results, lower overhead in encoding, hashing and memory allocation, and background recovery snapshots. The measurements below keep only one batch in flight at a time.
AWS c9gd.xlarge * 3 cluster · Two million accounts
| Execution mode | Commands per batch | Completed commands/s | Completion latency, p99 |
|---|---|---|---|
| Verify mode | 256 | 160.4–171.8K | 1.960–2.094 ms |
| Verify mode | 1024 | 207.8–209.2K | 5.405–5.417 ms |
| Performance mode | 256 | 239.9–241.7K | 1.537–1.575 ms |
| Performance mode | 1024 | 312.0–314.5K | 3.565–3.594 ms |
These runs include checkpointing, which saves recovery snapshots in the background: a capture every 64 log entries, with each selected snapshot kept for at least 1,000 ms, alongside normal disk syncs. They use AWS local instance storage, two million prefilled accounts and 2 GiB of engine capacity per node. The client sends the next batch only after receiving the previous batch’s result. Larger batches spread replication cost over more commands but take longer to complete.
AWS benchmark setup
Measured with AWS local instance storage, two million prefilled accounts and 2 GiB of engine capacity per node. Each configuration uses two 60-second runs, with the required sync calls and background checkpointing. See the benchmark notes for configuration and measurement definitions.
Local RAM-backed storage · Two million accounts
October 3, 2026
Ryzen 9 9950X3D, Linux, three nodes in one process communicating over TCP, with the real Bank engine and 2 GiB capacity per node. Both modes use 256 commands per batch. One client waits for the previous batch’s result before sending the next. Accounts are prefilled before timing, and requests touch accounts in scattered order.
| Execution mode | Completed commands/s Median (range) | Completion latency, p99 |
|---|---|---|
| Verify mode | 214.9K 191.3–215.2K | 2.585–2.897 ms |
| Performance mode | 333.0K 330.3–334.2K | 1.150–1.212 ms |
These tests include background checkpoints (a capture every 64 log entries, each selected snapshot kept for at least 1,000 ms) and required sync calls. All six runs completed without failed commands or unknown outcomes, and every replica caught up. The Linux RAM-backed filesystem (tmpfs) loses data on power loss. These are single-machine measurements. See the benchmark setup for the runner and measurement definitions.