The request that starts it is almost never about compute. Someone in physical security extends camera retention from 30 days to 90. The backup team adds a dozen application servers to the protection scope. Legal comes back with a revised retention schedule that says seven years where it used to say three.
None of those asks require another processor. In a hyperconverged environment, all three tend to end the same way: a quote for another node.
That node arrives with CPUs, memory, hypervisor licensing, a support contract, power draw, and rack space. The workload that triggered the purchase will use almost none of it. You bought a general-purpose compute platform to hold video footage that will be watched by no one and deleted on schedule.
The architecture is doing exactly what it was designed to do
This is worth saying plainly, because it often gets framed as a defect. It isn’t. Hyperconverged infrastructure collapsed compute and storage into a single unit on purpose, and that decision solved real problems: fewer things to manage, one support relationship, predictable expansion, no SAN fabric to maintain. For clusters where compute and capacity grow at roughly the same rate, the model holds up well.
The trouble starts when they don’t grow at the same rate. In a converged architecture, the fastest-growing resource sets the size of everything else. If capacity is what’s climbing, capacity is what dictates node count, and every unit of storage you add drags a full server behind it.
You don’t have to take a storage vendor’s word for this. According to VMware’s Cloud Foundation documentation, asymmetric growth is the first use case listed for its disaggregated vSAN Max architecture, described as the ability to “grow storage capacity and performance that is completely independent from your compute resources.” The same guidance notes that disaggregation lets customers run “extremely small vSphere clusters to reduce licensing costs.” Nutanix sells storage-only nodes for the same reason and has published side-by-side comparisons of how to scale capacity without scaling everything else. Analysts at Futurum put it more directly, observing that in conventional HCI “the infrastructure does not support independent scaling of those resources.”
When both major HCI vendors ship a product to solve a problem, the problem is real. The interesting question is what you do about it, and whether the answer has to come from the hypervisor vendor.
There’s a second cost that rarely makes it into the business case. Capacity added inside a cluster is not operationally free. Nutanix’s own comparison of capacity scaling notes that vSAN rebalancing “can impact the I/O performance of your vSAN cluster,” and that newly added capacity sits idle until a rebalance runs or new VMs are placed. Growing storage inside the cluster means the cluster does work to absorb it, and that work competes with production.
Three workloads generate most of the imbalance
In practice, asymmetric growth is rarely caused by your database tier or your application VMs. Those scale in something close to proportion. The imbalance almost always traces back to three specific tenants.
Start with video surveillance. Camera counts go up, resolution goes up, and retention windows get extended by policy or statute rather than by anyone’s preference. The resulting capacity curve has no relationship to compute demand, because footage is written continuously and read almost never. A retention change agreed in a compliance meeting can add hundreds of terabytes to a cluster that gained no new workloads at all. Nexsan® has written before about the operational challenges specific to surveillance storage at scale, and retention math is consistently the one that catches teams off guard.
Backup repositories behave similarly, with a compounding factor. Backup data grows as a multiple of production data, then grows again with every added restore point and every extension of the retention chain. It is also the data you least want sharing a fault domain with the workloads it protects. Housing backup chains inside the same cluster that runs production is a resilience question before it is a capacity question.
The third case is long-term file archive and compliance retention: records held for seven or ten years under a regulatory schedule, project data nobody will open again but nobody is permitted to delete. This is the purest version of the problem, because the retention period is set by a framework and the access frequency is effectively zero.
The three have the same shape. Written once, read rarely, indifferent to latency, and sized by a policy document rather than a performance requirement. In a converged cluster, all of it sits on premium clustered storage beside your production VMs and gets priced that way. The logic is familiar from paying flash prices for data that doesn’t need flash, one layer up: this time the mismatch runs past the media and into the chassis.
What changes when capacity stops arriving in node form
The alternative is straightforward, and it predates HCI: put the capacity-heavy data on a system built to hold capacity-heavy data, and let the cluster run what the cluster is good at.
The practical objection has always been integration friction. That objection has weakened considerably. Nexsan and Scale Computing published a validated joint architecture in April 2026 built around exactly this split, with performance-sensitive workloads staying on the SC//HyperCore cluster and capacity-heavy datasets living on external Nexsan systems. The solution brief names the problem in almost the same terms used here: “data growth (surveillance footage, images, files, backups) outpaces compute growth.” A parallel validation with Vates covers XCP-ng environments across iSCSI, NFS, and Fibre Channel, with no proprietary drivers on either side.
What attaches depends on the workload. Unity™ NV-Series covers mixed environments where the same platform needs to serve block, file, and object, with immutable snapshots and object locking included rather than licensed separately. BEAST is the density play for surveillance retention and archive, where the requirement is terabytes per rack unit at a defensible cost per terabyte. For teams already standardized on Veeam, the VHR™ Series puts the backup repository on hardened, purpose-built infrastructure instead of inside the cluster it’s meant to protect.
The protocols involved are ordinary: iSCSI, NFS, SMB, S3. That’s the point. Disaggregation only works if the storage tier is standards-based, and a tier you can attach to any hypervisor is worth more over a seven-year life than one that only speaks to the hypervisor you happen to run today.
See how Nexsan attaches to hyperconverged environments if you want the configuration detail.
The timing argument is unusually strong right now
Buying compute you don’t need is always wasteful. It is more wasteful during a capacity shortage.
Western Digital has confirmed its hard drive production is sold out for the entirety of 2026, with hyperscaler purchase orders extending into 2027 and 2028. NAND contract pricing moved more than 50% in a single quarter. In that market, every terabyte you acquire should be acquired as efficiently as possible, and buying it bundled with processors, memory, and per-node licensing is close to the least efficient way available. We’ve made the case for what deferring a storage decision actually costs and run the updated arithmetic on a petabyte. The node-shaped version of that math is worse than either, because the waste is structural rather than circumstantial.
The next capacity request is already coming
Someone is going to extend a retention policy this quarter. That’s not a prediction, it’s just how retention policies behave.
The question worth settling before it lands is whether your architecture has any way to answer a capacity request that doesn’t involve buying compute. If the only available response is another node, then your cluster isn’t being sized by your workloads. It’s being sized by whichever policy committee last met.
Talk to a Nexsan engineer about what a disaggregated capacity tier would look like in your environment.