The Missing Storage Layer in the Neocloud Stack
Hyperscalers built their storage economics around software designed for high-capacity hard drives. That software remained largely proprietary – until now, as the same principles become available to GPU clouds looking to build a more efficient capacity layer.
The economics of hyperscale storage were not created by buying more flash. They emerged from a different approach to the capacity layer: combining high-density hard drives with software engineered around their physical characteristics.
That distinction matters as neoclouds scale. GPU infrastructure makes the performance tier highly visible; the capacity estate behind it is less visible, but increasingly consequential. Checkpoints, model artifacts, datasets, logs and inference-related data continue to accumulate after the highest-performance phase of a workload has passed.
The question is therefore not whether flash or HDDs are “better”. They solve different problems. The more interesting question is whether the software layer between the application and the drive is designed to extract the economics available from modern high-capacity HDDs.
The hyperscale lesson is in the software layer
The public record of hyperscale infrastructure shows a recurring pattern: large cloud operators invested heavily in storage software that was co-designed with the characteristics of their underlying hardware. Their advantage was not simply access to inexpensive disks; it was the ability to make those disks useful at scale.
Much of that engineering remained internal. The industry consequently developed a familiar abstraction: storage software should be hardware-agnostic, while the hardware itself should absorb the complexity.
That abstraction works well when the underlying media behaves predictably. It becomes less efficient as drive capacities rise, recording technologies evolve and the cost of moving data across large fleets becomes material.
This is the part of the hyperscale model that is worth revisiting: not copying a hyperscaler architecture, but asking what becomes possible when the filesystem understands the physical layer it is managing.
Flash-first was rational for the performance tier
For GPU training, latency and sustained bandwidth can translate directly into accelerator utilisation. Flash therefore has a clear role in the performance tier, particularly where the workload repeatedly accesses data at high rates.
Training generates checkpoints, model artifacts, evaluation data, logs and other outputs whose useful life can extend well beyond the active training run. Some will be revisited frequently; much will not. Treating all of that data as if it has the same performance requirement can make the storage architecture increasingly expensive as the fleet grows.
This is not an argument against flash. It is an argument for making the capacity tier an engineered part of the architecture rather than a residual destination for data that no longer belongs on the performance tier.
AI growth is also a capacity-management problem
The assumption that more AI automatically means simply buying more storage is already being questioned. A September analysis from BigDATAwire framed the issue directly: More AI, More Storage? The Data Says It’s Not That Simple. The argument is not that AI will reduce storage demand — it is that increasing capacity requirements need to be considered alongside how existing data is actually used.
That distinction is supported by recent enterprise storage data. CTERA’s September 2026 analysis of 16 PB across 856 enterprise NAS file-share scans found that only 4.4% of stored capacity was actively used under its study definition. Some 83.1% of capacity was in files that had not been modified for more than a year, while only 9.9% of stored data was accessed during any given 90-day period. These figures describe enterprise NAS environments, not neocloud infrastructure, so they should not be extrapolated directly to AI clouds. They do, however, illustrate an important systems-level point: capacity and activity are not the same thing.
That distinction becomes more consequential as AI workloads expand. Training generates checkpoints, model artifacts, evaluation data, logs and other outputs whose useful life can extend well beyond the active training run. Some will be revisited frequently; much will not. At the same time, data that appears inactive today may acquire new value when AI systems make it easier to search, retrieve or analyse.
The storage question is therefore more nuanced than either “AI needs more storage” or “most stored data is cold.” It is about matching data to the infrastructure economics appropriate to its access pattern, retention requirement and expected future value.
For a neocloud, that makes the capacity layer strategically relevant. The challenge is not simply how much data exists, but how much infrastructure is required to keep that data available, protected and economically viable at the required level of performance.
The missing layer is hardware-aware storage software
Leil’s approach starts from that observation. LeilOS is HDD-native: a distributed parallel file system and storage operating environment designed around the behaviour of modern high-capacity HDDs, including host-managed SMR.
The objective is not to turn HDDs into flash. It is to make the properties that make HDDs economically attractive usable at scale: high areal density, sequential throughput, capacity growth, mixed generations and longer hardware lifecycles.
The distinction is important. A capacity tier does not have to mean a low-performance tier. If the filesystem can schedule work appropriately, exploit sequentiality, manage erasure coding and account for the characteristics of the media underneath it, high-capacity HDDs can serve demanding sequential workloads without being treated as an afterthought.
Leil’s published measurements illustrate the approach. In a June Solution Brief, a reference system using host-managed SMR drives from two manufacturers, 6+2 erasure coding and a single client driving the node through the filesystem achieved write efficiency of approximately 99% of the theoretical physical limit, while sequential SMR throughput tracked CMR performance in the tested configuration.
The important point is not the headline number. It is what the measurement says about the architecture: the software layer can determine how much of the physical capability of the media is actually made available to the application.
SMR changes the software equation
SMR is often discussed as a drive characteristic, but at scale it is equally a software-design question. The additional density is valuable only when the storage stack understands the constraints and opportunities introduced by the recording technology.
That is why the transition from CMR to SMR should not be viewed simply as a media refresh. It is an opportunity to reconsider the relationship between the filesystem, data placement, rebuild behaviour and the physical drive.
LeilOS is designed around that relationship. It supports host-managed SMR in its production write path and allows CMR and SMR generations to coexist within the same cluster. The result is a capacity architecture in which a drive refresh can be additive rather than automatically becoming a migration project. (cite)
This is the deeper implication of HDD-native design: the value is not in supporting a particular drive type. It is in making the storage software responsive to the physical system beneath it.
The next drive refresh is an architectural decision
The HDD roadmap makes this question increasingly relevant. Higher-capacity nearline drives are increasingly incorporating SMR, while CMR remains important for workloads and systems that require it. For storage operators planning several years ahead, the issue is therefore not simply which drive to buy next, but whether the storage software can accommodate the media roadmap.
That creates a useful test for any capacity architecture: how much of the next drive generation can be adopted without redesigning the storage system around it?
A storage layer that can mix generations and recording technologies changes the economics of refresh. Capacity can be added progressively; older hardware can remain productive where appropriate; and the organisation is less dependent on a single media configuration.
For a neocloud, this is ultimately a question of optionality. The capacity tier becomes more valuable when it can evolve with the drive market rather than forcing the storage architecture to evolve at the same pace.
From infrastructure cost to a storage product
There is also a commercial implication.
If the capacity tier can deliver predictable performance at substantially lower media cost than the performance tier, it does not have to remain an internal cost centre. It can become part of the service architecture offered to customers: a place for checkpoints, datasets, model artefacts and other high-volume data that needs to remain accessible without consuming the economics of the GPU-adjacent tier.
That is a different way of looking at storage. The question moves from “where do we put the data after training?” to “what storage services can we offer across the full lifecycle of AI data?”
The answer will differ by workload, retention requirements, customer expectations and infrastructure model. But the underlying economics are increasingly difficult to ignore: not every byte requires the same media, and not every high-capacity workload requires a cold archive.
The opportunity is to examine the layer between compute and capacity
The next generation of neocloud infrastructure will be shaped not only by GPUs and networking, but by how efficiently the resulting data estate can be retained, served and expanded.
That makes the storage layer behind the performance tier worth examining in its own right.
Leil is working with a small number of design partners ahead of the next major HDD refresh cycle to evaluate that architecture in real environments — from drive selection and capacity planning through workload behaviour, performance and lifecycle economics.
For organisations planning large-scale AI infrastructure, the useful starting point is not a commitment to a particular storage technology. It is a closer look at the data lifecycle, the physical media underneath it, and the software layer connecting the two.
That is where a significant part of the next storage economics will be decided.
The opportunity is to examine the layer between compute and capacity
For neoclouds, storage architecture also increasingly intersects with questions of jurisdiction, customer control and data residency. The physical location of capacity, the software operating it and the legal framework governing the data are becoming part of the infrastructure proposition.
For a broader discussion of this dimension, see Leil’s coverage of Data Sovereignty in the AI Era.
Author: Alexander Ragel
Alexander Ragel is the CEO of Leil Storage, an Estonia-based storage infrastructure company building HDD-native software for the exabyte era. Leil is in active co-engineering partnership with Western Digital, validated across the WD, Seagate, and Toshiba drive ecosystems.
