Your agents. Read and write faster.
Part 1 measured reads: ABS was 14–17% faster. Then we measured writes, where the lead is bigger still — 24–28% faster at sustained load and first in all 18 runs.
faster task completion vs AWS io2 · cold reads, 100k tasks
Read Part 1 →faster end-to-end vs the best AWS platform · 100k checkpoints
WAL fsync · AOF append · vector upserts · every commit waits on disk
100,000 checkpoints total
Agents read context and write state. Part 1 measures the read path: cold vector search, cache and checkpoint reads at 100k tasks. Part 2 measures the write path: state-serialization checkpoints that fsync after every agent step. ABS finishes first on both, and the lead grows with load.
Summary · Every checkpoint waits on disk. ABS waits the least.
Agent runtimes serialize state and commit a checkpoint after every step: small synchronous writes that must fsync before the agent proceeds. We benchmarked that write path on the same five platforms as Part 1 — pure checkpoint cycles (write) and read-context-then-commit (mixed), three scales, three runs each. The four numbers that matter:
ABS finishes first in all 9 write and all 9 mixed runs , with the margin growing from ~10% at moderate load to 24–28% at sustained load.
105–107 ms vs 210–232 ms at 100k checkpoints (write, steady state). 79–82 ms vs 158–175 ms in mixed mode.
918–925 ms vs 1,332 ms+ (write) · 980–1,132 ms vs 1,487 ms+ (mixed) at 100k checkpoints.
Lower than every AWS platform’s worst (566–744 ms) in steady state, while its typical window is roughly half theirs.
Background · Your agent doesn’t proceed until the disk says so.
A LangGraph-style runtime commits a checkpoint after every step: serialize agent state, INSERT + COMMIT to the checkpointer, update the latest-state pointer, persist new memories. Each is a small synchronous write that must reach disk — the agent’s next step is blocked on fsync.
Part 1 measured the read side: ABS was fastest end-to-end in all 9 runs. The open question this suite answers: does that hold on the write path, and does dynamic IOPS hold predictable latency bounds under sustained write pressure? Checkpoint payloads grow with step count (2 KB base + 2 KB per step, capped at 64 KB), mimicking accumulating message history.
On a write benchmark the fsync policy is the result, so it’s identical on all five platforms and documented: Postgres synchronous_commit=on (every COMMIT waits on WAL fsync), Redis appendonly yes (AOF, everysec default with an always variant), Qdrant WAL defaults with wait=true upserts. No platform gets a durability discount.
The setup · One checkpoint cycle. Three disk-bound commits.
Same five platforms and VM shapes as the read suite (4 vCPU · 16 GB · 256 GB), same preloaded 5M-vector dataset across 50 Qdrant collections, so writes land on realistically filled volumes. Each task is one checkpoint cycle:
| Op | What it models | Disk path |
|---|---|---|
| Postgres INSERT + COMMIT | Serialize agent state to the checkpointer | WAL fsync · commit waits on disk |
| Redis SETEX | Latest-state pointer | AOF append |
| Qdrant upsert · 5 vectors · wait=true | Agent memory write, random tenant | Qdrant WAL |
- What it models
- Serialize agent state to the checkpointer
- Disk path
- WAL fsync · commit waits on disk
- What it models
- Latest-state pointer
- Disk path
- AOF append
- What it models
- Agent memory write, random tenant
- Disk path
- Qdrant WAL
Two modes run back-to-back — write: pure checkpoint cycles, commit-latency bound; mixed: each task first reads context (1 Qdrant query, 1 Redis get, 1 Postgres select), then commits — the realistic agent-runtime shape. 10 concurrent workers, matching Part 1. Upsert IDs are deterministic per (agent, task), so repeat runs overwrite the same points instead of growing the dataset.
1 FIO · Writes are a closer contest than reads. io2 wins raw fsync.
4K random write (O_DIRECT, QD=64×4) plus a QD=1 --fsync=1 test; fsync latency is the number that predicts checkpoint commit latency. Two honest signals: ABS’s write floor (35K–104K IOPS) is a far closer contest than its 261–313K read floor, and io2 beats ABS on raw fsync latency (~1.0 ms vs 1.1–1.9 ms) while gp3’s ~2.7 ms fsync handicaps it at any provisioned IOPS.
| Platform | Random write IOPS (range, 3 runs) | Fsync latency (range) |
|---|---|---|
| Nirvana ABS | 35,079–104,083 | 1.13–1.91 ms |
| io2-32k | 33,052–33,071 | 0.97–1.06 ms |
| io2-64k | 40,321–40,342 | 0.99–1.08 ms |
| gp3-16k | 16,507–16,530 | 2.73–2.80 ms |
| gp3-3k | 3,083–3,097 | 2.73–2.75 ms |
- Random write IOPS (range, 3 runs)
- 35,079–104,083
- Fsync latency (range)
- 1.13–1.91 ms
- Random write IOPS (range, 3 runs)
- 33,052–33,071
- Fsync latency (range)
- 0.97–1.06 ms
- Random write IOPS (range, 3 runs)
- 40,321–40,342
- Fsync latency (range)
- 0.99–1.08 ms
- Random write IOPS (range, 3 runs)
- 16,507–16,530
- Fsync latency (range)
- 2.73–2.80 ms
- Random write IOPS (range, 3 runs)
- 3,083–3,097
- Fsync latency (range)
- 2.73–2.75 ms
AWS floors are pinned by provisioned IOPS and reproduce within ±0.1% across all 9 runs. ABS has no fixed provisioned cap, so its floor swings run to run, yet its application-level results are the most stable of any platform (≤2% duration spread in steady state). The raw-disk floor is a ceiling, not a guarantee; the checkpoint results below are what your agents actually feel.
2 ABS finishes first in all 18 runs. The lead grows with load.
Three scales (1k, 10k, 100k checkpoints), two modes, three runs each. ABS wins end-to-end duration in every single run — ~10% margin at moderate load, 24–28% (write) and 25–27% (mixed) at sustained load, where task p99 is 33–34% lower too.
R1 of the 10k and 100k scales is the first-insert run: Qdrant upserts create new points, triggering HNSW index growth and segment merges — a much heavier disk workload. R2/R3 are steady-state overwrite runs (deterministic IDs re-write the same points). Both are legitimate: first-insert is what ingest looks like; steady-state is what checkpointing looks like. gp3-3k collapses in first-insert at 10k checkpoints (606 s vs ~402 s steady): index-growth I/O saturates its 3,000-IOPS ceiling.
1,000 agents × 100 tasks · 100,000 checkpoints · write · run R3
| Platform | Duration | Task p99 |
|---|---|---|
| Nirvana ABS | 75 min | 919 |
| io2-32k | 105 min | 1,392 |
| io2-64k | 111 min | 1,449 |
| gp3-16k | 107 min | 1,389 |
| gp3-3k | 102 min | 1,392 |
- Duration
- 75 min
- Task p99
- 919
- Duration
- 105 min
- Task p99
- 1,392
- Duration
- 111 min
- Task p99
- 1,449
- Duration
- 107 min
- Task p99
- 1,389
- Duration
- 102 min
- Task p99
- 1,392
Durations are VM-side wall clock for the whole workload; task p99 in ms. ABS leads duration in every scale, mode, and run.
2.1 At sustained scale, everything flips to ABS.
At 10k checkpoints, io2-32k and gp3-16k hold the best per-op Postgres commit tail (78–88 ms vs ABS’s 95–105 ms): io2’s ~1.0 ms fsync floor showing through, the same moderate-load pattern as Part 1. Crank to 100k and it inverts: ABS holds half the Postgres commit p99 and the lowest Qdrant upsert p99. AWS’s fixed IOPS ceilings become the constraint; dynamic IOPS absorbs the load.
| Backend p99 (steady state) | gp3-3k | gp3-16k | io2-32k | io2-64k | Nirvana ABSwinner |
|---|---|---|---|---|---|
| Postgres commit · write | 217–219 ms | 212 ms | 210–213 ms | 224–232 ms | 105–107 ms |
| Qdrant upsert · write | 667–699 ms | 374–386 ms | 371–381 ms | 395–398 ms | 254–282 ms |
| Postgres commit · mixed | 166–175 ms | 165 ms | 158–163 ms | 170–171 ms | 79–82 ms |
- gp3-3k
- 217–219 ms
- gp3-16k
- 212 ms
- io2-32k
- 210–213 ms
- io2-64k
- 224–232 ms
- Nirvana ABS· winner
- 105–107 ms
- gp3-3k
- 667–699 ms
- gp3-16k
- 374–386 ms
- io2-32k
- 371–381 ms
- io2-64k
- 395–398 ms
- Nirvana ABS· winner
- 254–282 ms
- gp3-3k
- 166–175 ms
- gp3-16k
- 165 ms
- io2-32k
- 158–163 ms
- io2-64k
- 170–171 ms
- Nirvana ABS· winner
- 79–82 ms
100,000 checkpoints, steady-state runs (R2/R3). gp3-3k is the only platform where mixed is slower than pure write: the added read IOPS push it past its ceiling (8,600–8,800 s, 2.6 s task p99). And one AWS-side surprise: all four AWS platforms get ~13% slower in steady-state overwrites vs first-insert (segment rewrite amplification); ABS absorbs the same shift with +6%.
2.2 Does dynamic IOPS hold predictable bounds? Read this both ways.
The question this suite exists to answer. A single aggregate p99 can’t distinguish "consistently 170 ms" from "150 ms with periodic 400 ms spikes," so we tracked p99 in 10-second windows across every 100k-checkpoint run.
| Platform | Median window p99 | Worst window p99 | Worst / median |
|---|---|---|---|
| Nirvana ABS · steady state (R2/R3) | 73–97 ms | 429–536 ms | 4.4–7.4× |
| Nirvana ABS · first-insert (R1) | 80–99 ms | 735–964 ms | 9.2–9.7× |
| io2-32k | 133–182 ms | 600–678 ms | 3.4–4.9× |
| io2-64k | 142–193 ms | 620–744 ms | 3.5–4.9× |
| gp3-16k | 140–181 ms | 611–715 ms | 3.4–5.1× |
| gp3-3k | 142–193 ms | 566–664 ms | 3.0–4.5× |
- Median window p99
- 73–97 ms
- Worst window p99
- 429–536 ms
- Worst / median
- 4.4–7.4×
- Median window p99
- 80–99 ms
- Worst window p99
- 735–964 ms
- Worst / median
- 9.2–9.7×
- Median window p99
- 133–182 ms
- Worst window p99
- 600–678 ms
- Worst / median
- 3.4–4.9×
- Median window p99
- 142–193 ms
- Worst window p99
- 620–744 ms
- Worst / median
- 3.5–4.9×
- Median window p99
- 140–181 ms
- Worst window p99
- 611–715 ms
- Worst / median
- 3.4–5.1×
- Median window p99
- 142–193 ms
- Worst window p99
- 566–664 ms
- Worst / median
- 3.0–4.5×
100,000 checkpoints. Median vs worst per-10s-window Postgres commit p99. Read both ways: EBS keeps a flatter ratio, ABS keeps the lower absolute worst window.
Worst-window / median ratio is 3–5× on every AWS platform vs 4.4–9.7× on ABS. If your SLO is written as "p99 never exceeds N× typical," EBS is easier to reason about.
In steady state, ABS’s worst 10-second window (429–536 ms) is lower than every AWS platform’s worst (566–744 ms), while its typical window is roughly half theirs. The high ratio is an artifact of the low baseline, not of taller spikes.
The genuinely wide ABS tail (735–964 ms worst windows) appears only in the first-insert regime — the run where HNSW index-growth bursts make the disk workload heaviest, the same run-to-run variance pattern observed in Part 1’s 100k-task runs. In steady-state checkpointing it does not recur.
3 Six things the write path taught us.
ABS wins end-to-end in all 18 runs.
Margin grows from ~10% at moderate load to 24–28% (write) and 25–27% (mixed) at sustained 100k-checkpoint load. Task p99: 33–34% lower.
Moderate load mirrors Part 1.
io2/gp3-16k hold the best per-op commit tail at 10k checkpoints (io2’s ~1.0 ms fsync floor showing through) while ABS wins throughput. At 100k everything flips to ABS: half the commit p99.
First-insert vs overwrite matters more than platform for some workloads.
Index-growth bursts cost 1.5× steady state on constrained platforms (gp3-3k: 606 s vs ~402 s at 10k checkpoints). Capacity-plan for ingest, not steady state.
gp3-3k is fine until it isn’t.
Indistinguishable from io2 at 1k checkpoints, survivable at 10k steady state, and 1.7× worse than everything at sustained mixed load (2.6 s task p99).
io2-64k again buys nothing over io2-32k.
Instance-capped at 40k IOPS, and marginally slower in most write runs. Provisioning more IOPS than the instance can push is pure spend.
Durability was never traded for speed.
Every platform ran synchronous_commit=on, AOF persistence, and wait=true upserts. The ABS margin is measured with every commit waiting on disk.
Open source. Run it yourself.
Same repo as Part 1, state-serialization-writes branch. All five VMs run identical instance size and workload code; storage is the only variable. Every step from terraform apply to the results JSON, including the per-10s-window timeseries, is in the repo.
Compute (identical across platforms)
- AWS instance
- m6i.xlarge
- Nirvana instance
- n1-standard-4
- vCPU · RAM
- 4 · 16 GB
- Disk size
- 256 GB (all)
Benchmark parameters
- Pre-loaded vectors
- 5,000,000 · 50 collections
- Checkpoint payload
- 2 KB + 2 KB/step · cap 64 KB
- Agents × tasks
- 100×10 · 500×20 · 1000×100
- Workers
- 10 concurrent
Postgres synchronous_commit=on · Redis appendonly yes (appendfsync everysec default, always variant available via redis_appendfsync) · Qdrant WAL defaults, upserts with wait=true. Workload shape and mode flags live in ansible/roles/benchmark-runner/defaults/main.yml.
Every step commits. Your agents read and write faster.
Reads (Part 1): fastest end-to-end in all 9 runs. Writes: fastest end-to-end in all 18 runs, with half the Postgres commit p99 at sustained scale and the lowest absolute worst-window latency — measured with every commit waiting on disk.
Powering AI, blockchain, and
databases
