How We Designed ABS for Sustained IOPS

Why always-on blockchain workloads break traditional storage — and how ABS was built to stay fast under continuous load.

When we started designing Accelerated Block Storage (ABS), we didn’t begin with hardware specs or benchmark targets. We started with what users were experiencing in production.

Teams running nodes, indexers, and analytics systems kept telling us the same thing: storage felt fast at first — then sustained load arrived, and staying fast became expensive.

On paper, modern storage looks great. NVMe is fast. Cloud block storage advertises high IOPS. Short benchmarks look impressive. But blockchain workloads don’t behave like traditional applications. They’re always on, with continuous reads and writes and sustained I/O pressure. Most storage systems, however, are still designed around the assumption that high I/O is temporary and that mismatch is where performance starts to break.

ABS was built to absorb sustained I/O by design.

The Core Bottlenecks of Existing Storage Systems

After researching existing block storage approaches, what we found wasn’t a single flaw, but a sequence of bottlenecks that emerge once I/O becomes sustained.

Bottleneck #1: Single-Host I/O Pressure
In traditional VM-local setups, storage lives on the same machine as the workload. That creates a hard architectural ceiling where all reads and writes pass through one host. As load increases, queues grow instead of throughput.

This model optimizes for proximity and simplicity. However, Under continuous I/O, the host becomes the bottleneck, not the disk. No amount of tuning fixes a single-lane road. You can optimize drivers, adjust queue depths, and fine-tune kernel parameters, but the architecture itself remains the limiter.

The ceiling has nothing to do with flash capability - it's imposed by where storage lives.

Bottleneck #2: Policy-Governed Throughput (Hyperscaler Storage)
Cloud block storage removes the single-host ceiling, but introduces a different constraint. In shared cloud environments, storage performance is governed by platform policies designed to protect multi-tenant infrastructure. Bursting is allowed, but only briefly. Sustained load triggers throttling, credit depletion, or escalating cost.

Bottleneck #3: Poor Parallel Resource Coordination
Once storage is no longer host-bound, another limitation appears inside the storage layer itself. Many systems still behave like collections of independent resources, each operating in isolation with no global coordination.

Under sustained load, this leads to uneven utilization where some resources are overloaded while others sit idle, and parallel capacity goes unused. The system underperforms not because resources are scarce, but because it can't use them efficiently.

Bottleneck #4: Contention Outside the Storage Layer
Finally, Even a well-designed storage layer can fail if it competes with unrelated traffic. Network congestion, management operations, and public-facing access can all interfere with I/O paths, turning good architecture into unpredictable performance.

The Design Decisions Behind ABS

Once the bottlenecks were clear, the design priorities followed naturally.

Decouple storage from compute
The first step was to stop treating storage as part of the server. By decoupling storage from compute, we removed hard limits imposed by individual machines - including host-level I/O ceilings, capacity constraints tied to server size, and failure scenarios that forced rebuilds instead of recovery. This alone doesn’t make storage faster, but it removes the first major choke point and creates space for real scaling.

Optimize for Parallelism
High IOPS doesn’t come from making one thing faster. It comes from doing many small things at the same time.

Instead of optimizing for the speed of a single disk, ABS is designed around how much parallel work the system can absorb at any moment, distributing data across resources, maintaining a global view of where data lives, and servicing requests concurrently rather than piling them into a single queue. This shifts the bottleneck away from individual components and toward total system capacity.

In this model, “burst” isn’t a special mode. There is a stable baseline the system is designed to sustain indefinitely. When activity spikes and unused capacity exists, workloads can temporarily consume more I/O. If the system is busy, the baseline holds. If there’s headroom, it’s used. Bursts come from real capacity, not borrowed time.

Isolate What Shouldn’t Compete
Finally, to keep performance predictable under sustained load, ABS isolates storage traffic, management operations, and customer-facing access so that external access patterns or administrative activity don’t degrade internal I/O behavior.

Together, these design choices allow ABS to sustain high I/O pressure while remaining stable, predictable, and scalable, exactly what always-on Web3 workloads require.

The Outcome: Why ABS Works

The result isn’t “magic IOPS.” It’s a system where:

Costs remain predictable, without paying premiums just to keep performance stable.
Sustained workloads don’t quietly degrade over time - no credit exhaustion, no throttling after hours of load.
Performance scales linearly with capacity.
Storage pressure is absorbed by the storage layer, not pushed into individual hosts, eliminating single machine I/O ceilings.

Spec highlights:

20,000 baseline IOPS per volume, sustained indefinitely
Up to 600,000 IOPS burst, using real available capacity, not unused credits
Sub-millisecond latency (~0.3–1.5 ms) with node-level colocation, even under sustained load
Scales from 32 GB to 4 petabytes without downtime or re-provisioning

For always-on Web3 workloads - nodes, indexers, analytics pipelines - this matters more than peak benchmark numbers. What matters is performance that holds after hours and days of continuous I/O, not just the first few minutes.

That’s why ABS avoids the performance cliffs and pricing traps common in traditional cloud block storage, and why teams use it to run real production workloads, not just pass benchmarks.