Block vs Object Storage for New Cloud Workloads

The object storage market hit $8.14 billion in 2024. It's projected to reach $9.49 billion in 2025. That's a 16% compound annual growth rate, and almost all of it traces back to AI, machine learning, and big data analytics chewing through data at a scale that didn't exist five years ago.

The underlying reason isn't complicated. Unstructured data (images, video, audio, documents, logs) now accounts for roughly 90% of all enterprise-generated data, according to IBM. That's the exact format object storage was built for. Block storage handles it worst. The market is moving because the workload mix already moved.

One number that surprised me when I first saw it: a 2025 cloud storage study found only 19% of cloud object data is genuinely cold. And 83% of IT decision-makers said they access archive tiers at least monthly. Object storage stopped being a digital attic a while ago. Most people just haven't updated their mental model of it.

The default that's quietly settling in across cloud infrastructure looks something like this:

• Object storage for anything that doesn't require low latency
• Block storage for databases, VMs, and latency-sensitive workloads

Not because one is better in some abstract sense. Because the workload mix has shifted toward what object storage is actually good at. Everything else in this piece is about what that means in practice, workload by workload.

Where Block Storage Still Earns Its Place

Block storage isn't going anywhere. It's just that its territory is better defined now.

Relational databases still need it. Transactional workloads require atomic, low-latency writes to specific records. Block's granular addressing is exactly what makes that work. Virtual machines need it too. Boot volumes, OS images, stateful applications tied to a single instance. This is where block storage feels most at home. And if sub-millisecond response time is a hard requirement rather than a preference, block delivers it in a way that object storage, accessed over HTTP, genuinely cannot.

The provisioned-performance cost model makes sense for these workloads. You know what you need. You pay for it. Done.

Where things get complicated is when teams reach for block storage out of habit rather than fit. A few friction points are baked into the model:

• It attaches to a single server. Sharing across nodes without additional software layers is not a native capability.
• Capacity is pre-provisioned. Scaling means manual resizing or over-provisioning to cover demand you're guessing at.
• No built-in metadata, no HTTP access, no search. Everything beyond raw I/O has to be bolted on.

For distributed workloads, variable-scale pipelines, and anything accessed by many nodes at once, those aren't minor inconveniences. They're structural mismatches. Block storage isn't broken. It just wasn't designed for what a lot of modern cloud infrastructure actually does.

Why AI Training at Scale Pushed Teams Toward Object Storage

AI training datasets are unstructured, enormous, and growing. Petabytes of images, text, video, audio. That's the profile object storage was built to handle. For datasets over a petabyte, it's not really a matter of preference. Block storage at that scale would require pre-provisioning capacity at costs that are genuinely orders of magnitude higher. The economics don't work.

Nearly 30% of cloud-based object storage deployments are at least 10 PB in size, per MinIO. At that point, legacy POSIX-style APIs get too chatty and third-party metadata databases start buckling under the weight.

The architecture that emerged for training makes intuitive sense once you see the whole picture:

• Datasets live in S3 or a compatible bucket
• Training jobs pull from the bucket
• Checkpoints write back to it
• Multiple training nodes read simultaneously. No single-attachment constraint.
• Data lifecycle is completely decoupled from compute. Tear down the cluster, the data stays.

The economic and architectural logic point to the same place. Object storage stores petabytes cheaply, exposes data to many nodes in parallel, and doesn't tie anything to a specific compute resource. For training, it's a clean system of record.

The catch is that storing data in object storage doesn't solve the hardest part. Getting it to GPUs fast enough is a different battle.

The GPU Starvation Problem That Storage Architecture Creates

More than half of organizations report data and storage bottlenecks that limit AI performance and scalability, per MinIO's 2025 analysis. And 57% say their data isn't AI-ready, even as experimentation keeps accelerating. These aren't planning failures. They're physics.

A modern GPU can consume 1 to 5 GB/s during training. An 8-GPU system needs 10 to 40 GB/s of aggregate storage throughput just to keep up. Each new GPU generation delivers 2 to 3x more compute throughput. Storage infrastructure rarely improves at that rate. The gap widens with every hardware cycle and nobody really talks about it the way they talk about chip improvements.

The ROI threshold most teams use for training infrastructure is GPU utilization at 85% or higher. Below that, you're paying for compute that's sitting idle waiting on data. In distributed training, the problem compounds further. Every node has to receive its batch before the next training step can begin. A storage stall on one worker holds up the entire cluster.

Meta's experience is the clearest illustration I've seen. Before building their Data PreProcessing Service, Meta saw a 56% data stall rate across training clusters. More than half of training time, GPUs were waiting on storage. Extrapolated across what the industry is spending on GPU capacity right now, that's not a performance inefficiency. It's a category of financial waste that most organizations aren't measuring precisely because it's invisible at the GPU utilization dashboard level.

The problem isn't that object storage is the wrong place to keep training data. Sequential fetches over HTTP from a standard S3 bucket just can't saturate modern GPU compute. The solutions that are emerging don't replace object storage. They sit in front of it.

How the Infrastructure Gap Between Object Storage and GPU Compute Is Being Closed

GPUDirect Storage is worth understanding because the numbers are striking. It eliminates the CPU as a middleman in data loading, streaming directly from storage to GPU memory. Meta's move to GPUDirect Storage lifted training throughput from 50 GB/s to 192 GB/s. That's a 3.8x improvement in model training speed from a storage architecture change, not a GPU upgrade.

The 2025 hardware baseline has shifted considerably:

• PCIe Gen5 NVMe SSDs exceeding 14 GB/s sequential reads are becoming standard for training-tier storage
• WEKApod is achieving 720 GB/s throughput from 8 storage nodes, powering 768 H100 GPUs
• Software-defined object storage with hardware-accelerated data services is delivering sub-millisecond access at speeds that used to belong exclusively to block and file storage, per MinIO

Purpose-built products are entering the market specifically for this problem. CoreWeave's AI Object Storage, announced in October 2025, is S3-compatible and built for GPU workloads from the ground up. Its LOTA technology caches frequently used datasets and prestages data directly on the local NVMe disks of GPU nodes, supporting up to 2 GB/s per GPU and scaling to hundreds of thousands of GPUs. AWS also moved in late 2025 to increase the maximum S3 object size from 5 TB to 50 TB, which simplifies storing large AI training datasets as single objects rather than forcing teams to split them.

The layering pattern that's settling in:

• Object storage as the system of record
• An NVMe-backed caching layer close to compute handling the hot data GPUs actually need during a run
• For datasets under 100 TB: copy directly to GPU cluster storage before training starts
• For larger datasets: stream from object storage or a high-performance managed file system, depending on where the throughput-versus-cost tradeoff lands

Object storage isn't being replaced. It's being given a faster front door.

Inference Has Different Storage Requirements Than Training, and Most Architectures Aren't Built for Both

Inference now represents 80 to 90% of AI compute usage. By volume, it's the dominant AI workload. Training gets most of the architectural attention. This is backwards, and the teams that realize it late tend to pay for it in production.

Training tolerates seconds of I/O latency. Inference demands sub-millisecond response times to meet production SLAs. These are not the same performance profile, and treating them as interchangeable is where a lot of architectures quietly fall apart.

What inference actually needs looks different from training in a few specific ways. Fast random access to model weights at load time looks more like block storage's strength than object storage's. Low-latency retrieval of context, embeddings, or RAG document chunks during a live request is a different problem than bulk throughput. And agents running multi-step tasks need stable, persistent workspace with context that survives across sessions and parallel runs.

The mismatch shows up in a predictable and painful way. Teams that built their training pipeline around raw S3 access patterns often discover at inference time that latency is the binding constraint, not throughput. Model weights stored in S3 and fetched cold on every container start is a latency problem. Paying for more object storage capacity doesn't fix it.

The filesystem interface re-enters the picture here. Inference pipelines that can treat object storage like a mounted drive (reading model weights and context files with standard file I/O) avoid the cold-fetch problem without maintaining separate block volumes for every model. That matters more operationally than it sounds. Maintaining a separate block volume per model variant in production is expensive and doesn't scale cleanly as you push more models into production.

Training and inference are different enough that a storage tier optimized for one will underserve the other. The answer is a layered architecture, not a choice between two storage types.

Large-Scale Analytics Workloads and Why Object Storage Fits Their Access Pattern

Analytics workloads have structural properties that favor object storage, and they're not subtle. Data is read heavily and written infrequently. Object immutability isn't a limitation here. It's a fit. Query engines like Spark, Athena, and BigQuery are designed to scan large datasets in parallel from object storage. They weren't designed to issue random IOPS against block volumes. Schemas evolve, and data lake architectures that store raw files in open formats like Parquet, ORC, and Avro and query them in place are a natural match for object storage's flat namespace and metadata support.

The cost argument compounds fast at scale. Paying for provisioned block IOPS on petabytes of historical data that gets queried twice a month is economically hard to justify. Object storage's pay-for-access model matches the actual access pattern.

That 2025 finding that 83% of IT decision-makers access archive tiers at least monthly is worth sitting with here because the common assumption, that analytics data is cold and barely touched, understates how actively organizations actually query historical records. A lot of what gets labeled "archive" is really just infrequently written data that gets read more often than people expect.

That said, analytics workloads do hit real friction in a few places:

• Millions of small Parquet partitions stress S3 request rates and per-request latency. This is a live issue on large pipelines, not a theoretical edge case.
• Iterative workloads like ML feature engineering or repeated scans of the same dataset pay the network round-trip cost on every pass.
• A caching layer close to compute eliminates repeated fetches for hot partitions without requiring changes to the underlying storage architecture.

Unstructured Data Pipelines and the Case for Treating Object Storage as a Filesystem

Unstructured data pipelines represent the majority of what enterprise AI systems actually process. Documents, images, audio, video, logs. That 90% unstructured figure from IBM isn't a projection. It's where things stand right now.

The old answer was to run everything through an ETL pipeline into a database before it became useful. That's expensive, slow, and lossy when you don't know the structure of the data ahead of time. Healthcare records, legal documents, financial filings, government data. These are domains where forcing a schema destroys information that turned out to matter. You can't go back and recover what the schema threw away.

Object storage changes the trade-off. Store the raw artifact. Process it at query or inference time. Preserve the original without schema coercion. No ETL tax.

The operational reality of running these pipelines surfaces a few recurring friction points. Agents and pipeline workers need to read, write, and execute against the same dataset rather than copying it into a scratch volume per job. Workflows that run shell commands, call CLI tools, or manipulate files expect a filesystem interface. PutObject and GetObject semantics don't map to how most tools were written. And full POSIX semantics matter in practice: atomic rename for safe checkpoint writes, file locking for coordination between parallel workers, memory-mapped file access for model weights. These aren't academic requirements. They come up regularly.

The gap object storage leaves is real. It's rich in scale and durability. But it's accessed via an API that most existing tools, agents, and application frameworks weren't built for. That's why teams building agent infrastructure or multi-node inference clusters often layer a filesystem abstraction over object storage. Archil is one option in this space, mounting object storage buckets as POSIX filesystems so that applications get the file-based access patterns they expect without giving up object storage's scale and elasticity.

The architecture that actually works isn't a choice between object and block. It's object storage as the foundation, with the right abstraction layer on top depending on whether the binding constraint is latency, throughput, access pattern, or cost. Getting that layering right is the real infrastructure problem. Storage type selection is just the first decision.