Rob Pankow 
A new class of cloud provider has emerged around a single resource: the GPU. Neoclouds are GPU-focused clouds that rent accelerated compute almost exclusively, run lean catalogs, lean on bare metal or thin VMs, and wire everything together with very fast networking. They are growing quickly, and they all compete on the same brutal metric. Are the customer’s GPUs busy, or are they sitting idle while the meter runs? That question looks like a compute question. It is really a storage question, and it is the reason the data layer is now a strategic decision for every neocloud operator.
Why Storage Decides Neocloud Economics
A neocloud’s economics are simple to state and hard to win. The provider buys or leases extremely expensive accelerators, then rents them out by the hour. The single number that determines profitability and customer retention is GPU utilization. If a customer’s GPUs are idle, the most expensive asset in the building is burning money and the customer is watching their training run crawl.
The market context makes the stakes larger. Analyst estimates put the neocloud market at roughly $35B in 2026 and project it toward something near $237B by 2031. Treat those as directional figures rather than hard fact, but the trajectory is clear: a lot of capital is flowing into GPU capacity, and every operator in that flow is judged on whether the GPUs they bought actually stay fed.
Here is the part that surprises people new to the space. Idle GPUs are usually not a GPU problem. They are a data problem. Training and inference pipelines stall when the storage layer cannot deliver checkpoints, datasets, and intermediate state fast enough to keep the accelerators saturated. A cluster of accelerators waiting on a slow read path is the most expensive failure mode in the entire stack. That is why the storage decision sits upstream of neocloud profitability, and why a new generation of high-end, appliance-based storage platforms has become the default supplier to the largest neoclouds, commanding premium valuations on the back of big capacity wins. Those incumbents are strong. The open question for operators is whether the proprietary appliance model is the only way to keep GPUs fed.
What Neoclouds Need From a Storage Layer
Strip the buzzwords away and a neocloud needs a handful of concrete things from its data layer. It needs throughput and low latency to keep accelerators saturated. It needs to scale out as fleets grow. It needs multi-tenancy and quality-of-service controls because one platform serves many customers at once. It needs cost efficiency, because storage spend is a direct tax on GPU margin. And increasingly it needs sovereignty and data residency, because neoclouds are expanding into sovereign datacenters and serving regulated, private-AI workloads in specific jurisdictions.
Those requirements pull in different directions, and the way an operator resolves them defines the platform. The table below compares three broad approaches across the criteria that matter most to a neocloud.
| Criterion | High-end proprietary appliance | DIY open source | simplyblock |
|---|---|---|---|
| GPU-feed throughput and latency | Excellent | Variable, tuning-dependent | Sub-millisecond, high IOPS over NVMe/TCP and NVMe/RoCE |
| Cost efficiency | High cost, proprietary | Low license cost, high ops burden | Erasure coding yields up to ~80% usable raw capacity, plus tiering |
| Multi-tenant QoS | Strong | Weak to moderate | Built-in multi-tenancy and per-tenant QoS |
| Software-defined, no lock-in | Appliance-coupled | Yes | Yes, hardware-flexible |
| Sovereign self-host | Vendor-dependent | Yes | Runs on bare metal, EU clouds, and on-prem |
The appliance route delivers outstanding performance, and for the largest frontier-scale buyers it is a proven choice. The trade-off is cost and proprietary coupling. The DIY open-source route avoids license fees but shifts the burden onto an operations team that has to hand-tune for the relentless I/O of AI workloads. The third column is where a software-defined block layer aims to land: appliance-class performance, open economics, and the freedom to run on whatever hardware the operator already owns.
Where simplyblock Fits
Simplyblock is not a high-end storage appliance, and it does not try to be one. It is the sovereign, cost-efficient, software-defined storage layer for neoclouds that want NVMe performance without appliance lock-in. That positioning fits three motions especially well: European and sovereign neoclouds that must self-host in-region, private-AI builders who need full control of their data path, and the managed service provider motion that neoclouds are increasingly moving into as they sell platforms to many tenants at once.
The technical foundation is built for the GPU-feed problem. simplyblock is NVMe-first and speaks NVMe over Fabrics across both NVMe/TCP and NVMe/RoCE, so operators can match the transport to their network. It is built on SPDK for sub-millisecond latency and high IOPS, uses distributed erasure coding to make up to roughly 80% of raw capacity usable, and tiers intelligently from NVMe to object storage to keep hot data fast and cold data cheap. Copy-on-write snapshots and clones make dataset and checkpoint management cheap, multi-tenancy and QoS isolate noisy neighbors across customers, and the Kubernetes-native CSI driver plugs straight into the orchestration neoclouds already run. It is agentic-ready and runs on the operator’s own bare metal, on European clouds, or on-prem. In simplyblock’s own benchmarks, this combination has sustained up to 99.4% GPU utilization on cost-efficient infrastructure, which is the number that actually shows up on a neocloud’s P&L.
If you are mapping the broader landscape, our rundown of European AI cloud providers shows where these operators are building, and the European data infrastructure stack shows how a sovereign storage layer slots into the rest of the platform.
🚀 Stop paying for GPUs that sit idle waiting on data. Simplyblock is the sovereign, software-defined storage layer that keeps neocloud GPUs fed, on your own hardware, without appliance lock-in. 👉 Explore simplyblock scale-out storage architecture
Questions and Answers
Why is GPU utilization a storage problem?
Because the GPUs only stay busy if data arrives fast enough to keep them busy. Training and inference pipelines constantly read datasets, write checkpoints, and shuffle intermediate state. When the storage layer cannot deliver that throughput at low latency, the accelerators stall and wait. The idle time shows up as wasted spend and slower customer jobs, so the metric a neocloud competes on is set, in large part, by the data layer feeding the fleet.
How does simplyblock compare to high-end storage appliances?
They solve the problem from different ends, and the honest answer is that they are positioned differently. The high-end, appliance-based platforms are the dominant incumbents for the largest buyers, with excellent performance at a premium price and proprietary hardware coupling. simplyblock is a software-defined, cost-efficient, sovereign block layer that runs on the operator’s own hardware with no appliance lock-in. For neoclouds that want NVMe performance with open economics and full control of where data lives, simplyblock is a strong fit. For frontier-scale buyers who have standardized on a proprietary appliance, those platforms remain a proven choice.
Can simplyblock run on a neocloud’s bare metal?
Yes. simplyblock is software-defined and hardware-flexible by design. It runs directly on the bare metal or thin VMs that neoclouds already operate, on European clouds, or on-prem, using the NVMe devices the operator already owns. There is no requirement to buy a dedicated storage appliance, which keeps the cost structure aligned with how neoclouds actually buy hardware.
How does this help European and sovereign neoclouds?
simplyblock can be self-hosted entirely in-region, so data residency and sovereignty requirements are met by running the storage layer on infrastructure the operator controls in the right jurisdiction. There is no dependency on a foreign appliance vendor or a hyperscaler-controlled data path. That makes it a natural sovereign storage layer for European neoclouds and for private-AI builders serving regulated workloads.
What about MSP and multi-tenant use?
Neoclouds are increasingly moving into the managed service provider motion, selling a platform to many tenants at once. simplyblock is built for that with native multi-tenancy and per-tenant quality-of-service controls, so one customer’s heavy I/O does not starve another. Copy-on-write snapshots and clones let an MSP provision and reset tenant environments cheaply, and intelligent tiering keeps the cost per tenant under control as the platform scales.
