AI took the RAM: what to do with your 2026 hardware plan

For the April-to-June quarter, TrendForce forecast conventional DRAM contract prices rising 58% to 63% over the previous quarter, and NAND — the stuff inside your SSDs — rising 70% to 75%. In one quarter. Nothing whatsoever inside your company explains that: the memory industry has redirected capacity towards AI data centres, and the rest of us buy what is left. If you have servers to refresh, a RAM upgrade pencilled in for September or a half-finished storage project, that increase is already inside your budget even though you never put it there.

We buy hardware. We run our own infrastructure on Proxmox VE and Ceph across several data centres, and we manage our customers' too, so we see this increase in the quotes that cross our desk. This post is about how we look at a purchase plan when a component's price moves like this — and about the two or three things worth deciding before September.

Three numbers, and none of them are your fault

The first is already above: second quarter of 2026, conventional DRAM up 58% to 63% quarter on quarter, NAND up 70% to 75%, per TrendForce's contract price forecasts. The reason the firm itself gives is pure industrial accounting: capacity reallocated towards server and AI applications, plus a catch-up pricing strategy to close the gap between segments. Manufacturers prioritise server memory because that is where the margin is.

The second belongs to the quarter we are in: server DRAM contract prices are expected to rise 13% to 18% in the third quarter of 2026, with NAND up 10% to 15%. Careful, these are different segments — the first figure is conventional DRAM, this one is specifically server DRAM — so it is not a slowdown from 60% to 15% within the same product. Even so it reads like good news, and it deserves a slow read: an increase that moderates is still an increase, now on an already expensive base. That is precisely what gets lost on whoever suggests "waiting until things normalise".

And the third explains the other two. TrendForce estimates that total RDIMM bit supply — the modules that go into servers — will grow only 15% to 20% year on year, significantly lagging projected server CPU shipments. In plain terms: memory bits are growing more slowly than the machines that need filling with them. When a component's supply grows more slowly than that of the machine that needs it, price becomes pure arithmetic.

The asymmetry that never makes the headline

Here is the part almost nobody mentions. In its 9 July report, TrendForce explains that several large US cloud providers signed multi-year agreements that prevent suppliers from raising their prices, and adds the consequence without decoration: this caps increases for them and, for the third quarter, shifts the primary source of server DRAM price rises towards customers without such agreements.

That is how a market in shortage works: buy in volume and years ahead and you get hedged; buy two servers in October and you don't. It's worth saying out loud because it changes the conversation with your supplier and with your finance director: you are on the side of the market that absorbs the volatility, and that is not a negotiating failure. Squeezing a salesperson won't fix it. Planning, on the other hand, takes a good deal of the sting out.

How this lands in your budget

In three ways, in order of how likely each is to hit you. The small upgrade: adding memory to a three-year-old server has always been the cheapest line in the catalogue and the one nobody budgets — you just do it — and it is exactly the one that suffers when DRAM moves like this. The half-finished project: the cluster whose first half was bought in January and whose second half was planned for after the summer, on an approved budget that no longer adds up. And flash: servers already account for more than 40% of global NAND bit demand, and TrendForce estimates a 4% to 5% supply deficit for 2026, so the fast tier of your storage — the NVMe drives where databases live, or a cluster's metadata devices — takes the hardest hit per TB.

Before you buy, look at what you already paid for

When someone asks us for "a memory upgrade", we look at how much memory is actually in use before quoting anything. Allocated and used are not the same number, and in a virtualised environment the gap is usually uncomfortably large. It is an unglamorous conversation that pays off particularly well this year.

What we look at, in this order: allocated versus actual usage per machine, with weeks of history rather than a snapshot from one Tuesday afternoon — this is where decent monitoring (Zabbix, in our case) stops being decoration and pays for itself; machines nobody ever switched off, starting with the test environment from that migration which finished in March; memory that looks used and largely isn't, such as system page cache or ZFS ARC, which does give memory back under pressure, though neither instantly nor below its configured minimum; and, in the other direction, nodes genuinely at their limit, where the answer is redistributing machines across the nodes you already have before buying anything.

One important warning for anyone looking at a hyperconverged node: what each Ceph OSD reserves does not belong in the expendable-memory bucket. The osd_memory_target is committed node budget, not cache you can reclaim when a VM gets hungry. Subtracting it from the maths is the fastest way to end up with an OOM node and a degraded cluster on the very day you set out to save money.

Proxmox VE ships two tools for squeezing this that are right there and free: ballooning, so a guest hands back memory it isn't using, and KSM, which deduplicates identical pages across similar guests — very handy when you run twenty Windows Servers cloned from the same template. Neither is magic and both come with small print: ballooning deserves care with latency-sensitive workloads, and KSM costs CPU and opens a side-channel path between guests — Proxmox's own documentation recommends disabling it if you host workloads belonging to different customers, and gives you a per-guest switch for exactly that. With those caveats up front, they are worth half an hour before signing a purchase order. And we say this without drama: most of the time the exercise shrinks the purchase rather than cancelling it. In 2026, shrinking it is almost always a good idea; postponing it, almost never.

Stretching hardware life: when it works and when it's a trap

The natural reaction is to stretch what you have for another year. Sometimes that is the right call: if warranty or support can be extended at a sensible price, if spares exist, if the machine is nobody's bottleneck, and if power consumption is part of the maths — depending on how many CPU generations separate it from current kit, the difference in performance per watt is paid every month — then stretching is reasonable.

And sometimes it's a trap: when the node you're stretching has already given you two scares, when the disks have accumulated so many hours that a rebuild after a failure becomes a lottery, or when the spares plan amounts to hoping you can find the same model second-hand. Deferring a purchase isn't saving money: it's trading money for risk. Sometimes that is an excellent trade. But make it with your eyes open, with a date written down and knowing what breaks if it breaks — not out of inertia, and certainly not because the price put you off.

This is not an automatic argument for or against the cloud

Someone will say it in a meeting this week: "let's just move to the cloud and make the problem go away". The public cloud buys memory in the same strained market you do; what it has, per the 9 July report, are the multi-year contracts you don't. That gives it short-term cover, but the volatility doesn't disappear: someone else absorbs it, and you see it — if you see it — later and without a line item on the invoice.

The question that matters is a different one: who carries the price risk, for how long, and in exchange for what. A purchased server is a cost you already know for the next five years; a monthly bill is flexibility at a price you don't set. Both positions are legitimate and we build both. We ran that full calculation a few days ago in colocation versus public cloud over five years; what has changed since then isn't the method, it's one of the variables — and it is worth putting back into the spreadsheet before you decide.

Design is money too, and more so now

When the price per TB of flash goes up, storage design stops being an engineering debate and becomes a budget line. A cluster on 3-way replication writes three copies: for every usable TB you buy three. Erasure coding can give you comparable tolerance with considerably less disk, in exchange for CPU, latency and a more expensive rebuild. We wrote the full 3-way replication versus erasure coding maths for Ceph a few days ago and the nuance hasn't changed: EC distributes the cost differently, it doesn't remove it. What has changed is the weight of one of the columns — and that justifies revisiting clusters designed back when disk was the cheap part of the budget.

How long does this last?

It's the obvious question, and on NAND there is a dated answer. TrendForce published on 21 July that supply growth will outpace demand in 2027 and that the current tightness should ease in the second half of that year, with Chinese manufacturers raising their share to nearly 19% of global bit production in 2027. And from the March report, the sentence that does the most to organise a spreadsheet, referring to enterprise SSDs: meaningful capacity expansion is unlikely until late 2027 or 2028.

Our reading, for what it is worth: plan on another twelve to eighteen months of high prices. That is the prudent assumption given what has been published, and it is the one we are working to. Any refresh plan that depends on this fixing itself by the autumn isn't a plan, it's a wish with a date on it.

Two columns before you sign anything

The exercise we are running on this year's purchase plans fits on a sheet split in two. On the left, what gets optimised before buying. On the right, what gets bought however ugly the price is. The point is that it forces every line into one of the two columns, with no comfortable "we'll look at it in September" box.

And underneath both columns, the boring thing that holds everything else up: a current inventory — what you have, under what warranty, until when. We keep ours in NetBox as the single source of truth. Without it, a refresh plan ends up being a conversation of opinions in which whoever talks loudest decides.

There is no brilliant decision to make here

The uncomfortable part of this year is precisely that: there is no clever architecture that gives you back 60% of the DRAM. What there is, is a context in which boring decisions — knowing what you have, measuring what you actually use, buying what you need rather than what reassures you — are worth considerably more money than usual. In normal years, 20% of over-provisioning is a minor imprudence nobody looks at. This year it shows up in the accounts.

And one practical question is worth answering in writing this year: if a key component goes up another notch next quarter, which purchase in your plan gets dropped, and who decides which one? Answering that in July costs a one-hour meeting. Answering it in October, with the order on the table and someone waiting, costs considerably more.

Sources (verified): 2Q26 contract price forecasts (conventional DRAM +58–63%, NAND +70–75%; capacity reallocated to servers/AI; on enterprise SSDs, "meaningful capacity expansion unlikely until late 2027 or 2028"), TrendForce, 31 Mar 2026. Server DRAM +13–18% QoQ in 3Q26, multi-year agreements by several CSPs shifting price pressure onto customers without them, RDIMM module migration from 96/128 GB to 32/64 GB, and RDIMM bit supply growth of 15–20% YoY: TrendForce, 9 Jul 2026. NAND +10–15% in 3Q26 and moderation driven by weaker consumer demand: TrendForce, 3 Jul 2026. NAND supply deficit of 4–5% in 2026, servers above 40% of bit demand, and easing expected in the second half of 2027: TrendForce, 21 Jul 2026. These figures are industry contract-price forecasts, not end-customer sale prices: what you pay also depends on your manufacturer, your volume and your channel. The pre-purchase review method is ours.