How your HCI platform counts capacity decides your flash bill

The memory market has turned structural rather than cyclical. DRAM contract prices rose 90 to 95 percent quarter over quarter in the first quarter of this year, with another 58 to 63 percent following in the second. NAND climbed 70 to 75 percent alongside it.

High bandwidth memory (HBM) sits at the root of it, and each HBM wafer displaces roughly three conventional DRAM wafers, so manufacturers follow the margin. New fab capacity reaches volume late this year at the earliest. Most analysts anticipate normalization in 2028 or 2029 , at a higher baseline than the one buyers left behind.

That shifts what matters in an infrastructure design. Through a decade of falling flash prices, a software license metered against capacity looked survivable. Every terabyte now carries a rising acquisition cost, and a software charge that scales with raw capacity compounds on top of it.

What the license actually counts

So the question worth asking an HCI vendor this year is what unit the license counts. Some platforms count two. They license per CPU core across every host in the cluster, and each licensed core also carries an entitlement of raw capacity, with anything past that entitlement billing separately in terabyte increments. The ratios are published. VMware Cloud Foundation includes one TiB of raw capacity per licensed core, vSphere Foundation includes a quarter of a TiB, and both carry a floor of 16 cores per CPU.

The ratio breaks as drives get denser

A fixed ratio per core held together when drives were small. Enterprise SSD capacity has gone from 15.36 TB to 245.76 TB in roughly six years, a factor of 16, while cores per socket went from 64 to 192 across the same window, a factor of three. Density is outrunning core count by about five to one, and a per-core entitlement is pinned to the slower of the two.

Run that against a current chassis. A 64-core host earns 64 TiB on the one-TiB ratio. Fill its 24 bays with 61.44 TB drives and the tray holds roughly 1,341 TiB of raw capacity, so the entitlement covers under five percent of it.

Both meters run on the same hardware

The two meters run on the same hardware at the same time, and that is what closes the obvious escapes. Every core in every host carries the per-core charge, and the capacity allowance those cores earn is a ration rather than a gift, paid for already through the core count. The included terabytes were never free .

Denser drives trip the capacity meter, while denser server counts trip the per-core one. Consolidating onto fewer, higher-core-count boxes keeps the core count roughly where it started, and one current two-socket server can carry more cores than three of the machines it replaces. Moving the other way, toward more and smaller nodes, runs into the per-CPU floor, which bills for cores a small host does not physically have.

Efficiency stops at the meter

One detail compounds it. These meters read raw physical capacity, counted before failure tolerance and before data reduction. Deduplication and thin provisioning lower what a team stores and leave the metered figure where the drives put it. That inverts the usual defense during a flash super cycle, because efficiency is the first tool buyers reach for when media gets expensive, and a raw meter ignores it.

Why teams go back to three tier

This is the mechanism that sends teams back to three tier. Priced against a per-core entitlement, capacity growth inside the cluster gets expensive, so the storage architect prices an external array and finds it charges by usable terabyte instead. The arithmetic picks the array. What arrives with it is a separate controller, a separate support contract, a separate refresh calendar, and a separate vendor to manage. The converged purchase was supposed to retire that tier. The licensing model rebuilt it.

Capacity metering is one of three schedules a converged purchase hands over. The support calendar sets the refresh date, and the compatibility list decides which servers qualify. I have covered those two separately, and the pattern behind all three is the same.

Licensing by the node changes the arithmetic

The alternative pattern is simple enough to check in a quote. Platforms licensed per node or per server, VergeIO among them, treat capacity as an engineering decision rather than a license event. Adding drives leaves the license where it was, and consolidating onto fewer, denser servers pulls it down. Both density levers start working for the buyer instead of against.

That distinction earns its keep in this market. Capacity bought inside a dedicated array arrives at the array vendor's price for the drive, qualified against the array vendor's own list, while capacity bought in a server is a server drive, sourced through the channel and shopped across suppliers.

The NAND underneath is often the same, though the purchasing position is not. When drive prices climb 70 percent in a quarter, the ability to shop the drive is worth considerably more than it was a year ago.

Questions to ask before signing

Software earns its license fee. The unit that fee counts is the part worth settling before signing. Ask a vendor what happens to the license when capacity doubles while compute stays flat, and what it does when the same data consolidates onto half as many, denser servers. Then run both scenarios again using the drive sizes the roadmap points at rather than the ones on the floor today.

A design that works on 15 TB drives can invert on 61 TB drives with no workload change at all. The rate is something a buyer negotiates at renewal, and the unit is something the architecture decides. In a market where the media is the scarce resource, a license counting nodes leaves a buyer more room than a license counting terabytes.

Contributed by Verge.io