Your Langchain Agents on Nirvana has Faster Reads and Writes.

ABS commits agent state 2x faster than AWS, and finishes the workload 24-28% sooner

TL;DR

• ABS wins end-to-end duration in all 18 runs (9 write, 9 mixed read+write)
• The lead grows with load: ~10% at 1K checkpoints, 24-28% at 100K checkpoints
• Half the Postgres commit p99 at sustained scale: ~105ms vs 210-232ms on every AWS tier
• Task p99 33-34% lower at sustained scale
• Same price gap as Part 1: $118/mo vs $3,710/mo for io2-64k (31x)
• io2-64k again performs identically to io2-32k (instance-capped at ~40K IOPS), and was marginally slower in most write runs
• Every commit durable: fsync pinned on all three services, 3 runs per scenario, fully reproducible

In our previous benchmark we measured the read path: cold vector search, cache lookups, and checkpoint loads across 100K LangChain agent tasks. ABS finished 14-17% faster than AWS io2 at every scale, with 19% more throughput, at 31x less cost.

But reads are only half of what an agent does.

This time: writes

Agent runtimes (LangGraph-style) serialize and commit a checkpoint after every step. These are small synchronous writes, and the agent waits: the commit must fsync to disk before the next step can start. Slow writes don't just slow retrieval, they slow thinking-to-acting.

This matters even more if your agents are disposable. Fresh-agent architectures move all state from the process to the disk. The checkpoint is the price of disposability, and it's paid on every single step.

So Part 2 benchmarks that write path. Same five platforms, same VMs, same 5M-vector dataset sitting on the volumes, so writes land on realistically filled disks.

Each task is one checkpoint cycle across the same three services:

• Postgres INSERT + COMMIT: serialize agent state, commit waits on WAL fsync
• Redis SETEX: latest-state pointer
• Qdrant upsert: agent memory write, wait=true

The checkpoint payload grows with step number (2KB base + 2KB per step, capped at 64KB), mimicking accumulating message history.

Two modes, run back to back:

• write: pure checkpoint cycles, commit-latency bound
• mixed: read context first, then checkpoint. The realistic agent-runtime shape.

On a write benchmark, the fsync policy IS the result, so it's pinned and documented: Postgres synchronous_commit=on, Redis appendonly, Qdrant upserts with wait=true. Every commit waits on the disk.

The setup

Identical to Part 1. The only variable is the block storage.

Config	Instance	vCPU / RAM	Storage	Provisioned IOPS	Cost / mo
Nirvana ABS	n1-standard-4	4 / 16 GB DDR5	ABS 256 GB	20K baseline, 600K burst, included	$118
gp3-3k	m6i.xlarge	4 / 16 GB DDR4	gp3 256 GB	3,000	$147
gp3-16k	m6i.xlarge	4 / 16 GB DDR4	gp3 256 GB	16,000	$212
io2-32k	m6i.xlarge	4 / 16 GB DDR4	io2 256 GB	32,000	$2,238
io2-64k	m6i.xlarge	4 / 16 GB DDR4	io2 256 GB	64,000	$3,710

Raw disk first: writes are a closer contest than reads

Honest numbers up front. On raw fio, the write race is much tighter than the read race was.

Platform	Random write IOPS	Fsync latency
Nirvana ABS	35K-104K (no fixed cap)	1.1-1.9 ms
io2-64k	40.3K (instance-capped)	~1.0 ms
io2-32k	33.1K	~1.0 ms
gp3-16k	16.5K	~2.8 ms
gp3-3k	3.1K	~2.7 ms

io2 wins raw fsync latency. gp3's ~2.7ms fsync handicaps it at any provisioned IOPS. And ABS's read advantage (7.8x on fio) shrinks to a close contest on writes.

Which makes what happens at the application layer more interesting, not less.

Task completion at scale

ABS wins duration in all 18 runs. The lead widens with load.

Steady-state numbers (checkpoint overwrites, write mode):

Scale	Checkpoints	Nirvana ABS	io2-32k	io2-64k	gp3-16k	gp3-3k	ABS lead
100x10	1,000	36s	39s	40s	40s	40s	~10%
500x20	10,000	362s	398s	417s	403s	402s	9-14%
1000x100	100,000	75 min	104 min	111 min	107 min	101 min	24-28%

Mixed mode (read context, then checkpoint, the realistic agent shape) at 100K:

Platform	Duration	Task p99
Nirvana ABS	84 min	980-1,132 ms
io2-32k	112 min	~1,490 ms
gp3-16k	115 min	~1,505 ms
io2-64k	120 min	~1,560 ms
gp3-3k	146 min	~2,650 ms

gp3-3k is the only platform where mixed is slower than pure write: the added read IOPS push it past its 3K ceiling and task p99 blows out to 2.6s. gp3 is fine until it isn't.

The commit path: where agents actually wait

Per-backend write p99 at sustained scale (100K checkpoints, steady state):

Backend p99	Nirvana ABS	io2-32k	io2-64k	gp3-16k	gp3-3k
Postgres commit (write mode)	105-107 ms	210-213 ms	224-232 ms	212 ms	217-219 ms
Postgres commit (mixed mode)	79-82 ms	158-163 ms	170-171 ms	165 ms	166-175 ms
Qdrant upsert (write mode)	254-282 ms	371-381 ms	395-398 ms	374-386 ms	667-699 ms

At moderate load (10K checkpoints), io2 and gp3-16k actually hold a better per-op commit tail than ABS, the same pattern as the read suite. At sustained load, everything flips: ABS holds half the commit p99 across the board.

Remember what this number means: the agent cannot take its next step until the commit returns. Half the commit p99 is not a storage stat. It's your agents stepping twice as fast under load.

Tail stability under sustained pressure

A single aggregate p99 can't distinguish "consistently 170ms" from "150ms with periodic spikes." So we logged p99 in 10-second windows through every 100K-checkpoint run.

In steady state, ABS's worst 10-second window (429-536ms) is lower than every AWS platform's worst (566-744ms), while its typical window runs at roughly half theirs (73-97ms vs 133-193ms). Lower typical latency, lower worst case.

One honest caveat: in relative terms EBS is flatter. Its worst window is 3-5x its median, ABS's is 4.4-7.4x. The ratio is higher because the baseline is lower, not because the spikes are taller. If your SLO is written as "p99 never exceeds N times typical," EBS is easier to reason about. If it's written in milliseconds, ABS wins both ends.

First-insert vs steady state: plan for ingest

The first run at each scale writes new vectors, which forces index growth, a much heavier disk workload than the steady-state overwrites of later runs. Two findings:

• On constrained tiers, the regime matters more than the platform. gp3-3k took 606s on first-insert vs 402s in steady state at 10K checkpoints, a 1.5x penalty.
• Moving from first-insert to steady state, AWS platforms all got ~13% slower (segment rewrite amplification). ABS absorbed the same shift with +6%.

Capacity-plan for ingest, not steady state.

Cost

Same platforms, same prices as Part 1.

Platform	Monthly cost
Nirvana ABS	$118
gp3-3k	$147
gp3-16k	$212
io2-32k	$2,238
io2-64k	$3,710

io2-64k was again identical to io2-32k, and marginally slower in most write runs. Double the IOPS bill, zero the benefit. The m6i.xlarge instance caps at ~40K IOPS regardless of what you provision.

Verdict

Reads were ABS's strong suit on paper: a 7.8x raw disk advantage that translated to 14-17% faster tasks. Writes were the skeptic's question: io2 wins raw fsync, so does the lead survive a commit-bound workload?

It didn't just survive. It grew. 24-28% faster end-to-end at sustained scale, half the commit p99, the lowest absolute worst-case windows, at $118/mo against $3,710.

If your agents checkpoint state (and if you run LangGraph, they do, after every step): ABS.

Open source. Run it yourself.

Same repo, new branch. Terraform configs, Ansible playbooks, benchmark runner, raw JSON results including per-10-second latency series.

Full report: https://nirvanalabs.io/benchmark-results/langchain-write

Repo: github.com/nirvana-labs-examples/langchain-benchmarks/tree/state-serialization-writes

Add your own storage config and compare.

---

About Nirvana Labs

Nirvana Labs is a high-performance storage cloud purpose built for blockchain, AI and databases i.e. the most demanding, real-time, stateful workloads. Accelerated Block Storage (ABS) offers 20K baseline IOPS included, no over provisioning. Nirvana Kubernetes Service (NKS) with Karpenter auto-scaling, high clock-speed compute and private networking. Backed by Jump Trading, Crucible, etc with 50+ customers live in production today.

Learn more at Nirvana Labs

Nirvana Cloud | Pricing | Blog | Docs | Changelog | LinkedIn |Twitter | Telegram| YouTube