What this is. Opinion + Experience + Fact (45% opinion · 20% experience · 35% fact). Written in collaboration with AI — I discuss, I do not outsource.

A wave note on the 2026 memory squeeze. A supply brief published on September 14, 2026 reports memory prices still rising and lead times running from 8 to 52 weeks depending on the part. Procurement is asking how to buy. Firmware has a question of its own: how little memory does the product actually need? A memory shortage is not just a purchasing problem.

Less margin you cannot justify, more parts that fit (simplified illustration) A bar shows the memory a product asks for: a fixed measured need plus a safety margin. As the margin is trimmed to what can be justified, the number of memory parts that would fit the design grows from two to five. Less margin you cannot justify, more parts that fit. Simplified illustration of the idea — not to scale, not a real memory map. measured need safety margin PARTS THAT FIT Memory you can measure is memory you can cut, and a part you can swap.
Trimming the safety margin to what the design can justify widens the set of memory parts that fit. Simplified illustration.

On September 14, 2026, VersaLogic, a maker of industrial computer boards, published a supply brief on memory market conditions and updated it on September 22. The headline for anyone who ships devices: prices for DDR3, DDR4 and DDR5 kept rising through August, and lead times run from 8 to 52 weeks depending on the product. The brief's own advice is that planning further ahead matters more than it did earlier this year.

That is good advice, and it is a purchasing answer. I would like to add the firmware half of the answer. Purchasing decides how early you buy. Firmware decides how much you need to buy, and how many different parts could do the job. This post is about that second lever.

1. Why is memory hard to buy in 2026?

Memory makers are steering capacity toward AI data centers. According to ByteSnap, an embedded design consultancy writing in April 2026, high-bandwidth memory takes roughly three times the wafer capacity of standard DDR5, and the three suppliers that make most of the world's DRAM are reallocating accordingly. ByteSnap reports typical lead times stretching from around eight weeks to 18 to 20 weeks or more in some cases, and projects meaningful relief no earlier than late 2027, when new fabrication capacity is scheduled to come online. That last point is a projection, and I treat it as one.

Samsung's own president put the wider picture plainly in January 2026, as reported by Network World: supply issues in 2026 were going to "affect everyone, not just Samsung." Device makers with smaller volumes than the big cloud buyers feel it in price and in waiting time.

▸ First principle. A shortage sits upstream of your schedule, so the flexible variable is your design.

2. What can firmware do about a memory shortage?

Firmware decides two numbers that end up on the bill of materials: how much RAM and flash the product asks for, and how tightly the design is tied to one particular memory part. Both numbers are usually chosen early, with a comfortable margin for "what if".

Here is the opinion part of this post. Every kilobyte of margin that nobody can justify is a constraint on sourcing. A design that asks for a lot of memory fits fewer parts, and a design tied to one part has no alternate when that part goes long. Trimming margin you can defend removing widens the list of parts that fit and shortens the conversation with procurement.

ByteSnap's suggestions point the same way: audit the bill of materials, and consider a lighter software stack, such as an RTOS instead of Linux, where the product allows it. Whether that fits your product is a design call, not a rule.

▸ First principle. Memory you can measure is memory you can cut, and a part you can swap.

3. How do you make memory need a number you can read?

In my experience, memory surprises come from open-ended things: queues that are allowed to grow, buffers sized "big enough", and tasks that share state. Each one turns "how much memory do we need" into a guess, and a guess needs a margin.

Bounded design closes those loops. In EmbedIQ, the open framework I work on, each task is a single thread with a table-based state machine and one message queue. The number of states and the depth of each queue are written down in the design. The Observatory records every transition, message and fault, so what the device really does is on record instead of estimated. Board-specific bring-up and drivers remain your work.

None of this fixes a shortage. What it gives you is facts, fast, on the day a memory part's lead time stretches: what the product needs, what it can live without, and which alternates fit. A related story, from the supply side, is in what to do when a component reaches end of life mid-production.

▸ First principle. Bounded design turns "how much memory do we need" from a guess into a reading.

The copyable part: a memory-shortage checklist for a connected product

QuestionWhat "yes" looks likeWho owns it
1. Do we know our real RAM and flash need?Peak use measured per task on real hardware, with the safety margin written down separatelyFirmware
2. Can we justify every kilobyte of margin?Each margin has a stated reason (worst-case burst, planned feature, update headroom) or it is trimmedFirmware + product
3. Are our queues and buffers bounded?Every queue has a fixed depth and every buffer a fixed size, written in the designFirmware
4. Which alternate parts fit the design?At least one qualified alternate memory part on the bill of materials for every memory lineHardware + procurement
5. Have we planned the buy far enough ahead?Lead-time assumptions checked against current supplier quotes, per partProcurement
6. Could a lighter software stack meet the need?The stack choice reviewed against measured need, for example an RTOS versus LinuxFirmware + architecture
7. Who decides when a part goes long?One named owner and one page of facts (need, margin, alternates) ready before it happensProduct lead

Seven questions, and only two of them are about buying. The rest are about how much you need to buy, and the answer to that lives in your firmware.

Hardware and firmware leads: has the memory market changed how you size RAM and flash on your next design?

Next in this thread: the log the crash erased — why the record of what a device did has to survive the failure it describes.

Sources

Market conditions: VersaLogic — Supply Chain Brief: Market Conditions in 2026 (published September 14, 2026, updated through September 22: DDR3, DDR4 and DDR5 prices rising through August; lead times 8 to 52 weeks depending on product; advice to plan further ahead). Capacity and design advice: ByteSnap Design — DRAM Shortage: Embedded Systems, What You Can Do Now (April 7, 2026: high-bandwidth memory uses roughly three times the wafer capacity of standard DDR5; lead times from around 8 weeks to 18 to 20 weeks or more in some cases; relief projected no earlier than late 2027; audit the bill of materials, consider an RTOS instead of Linux). Supplier statement: Network World — Samsung warns of memory shortages driving industry-wide price surge in 2026 (January 7, 2026). The figures are the sources' own; the reading of them, and the design position, are mine.

FAQ

Why is there a memory shortage in 2026?
Memory makers are steering production capacity toward AI data centers. High-bandwidth memory for AI uses roughly three times the wafer capacity of standard DDR5, so less capacity is left for other memory. According to a September 14, 2026 supply brief, DDR3, DDR4 and DDR5 prices kept rising through August.

How long are memory lead times right now?
A supply brief published September 14, 2026 (updated September 22) reports lead times from 8 to 52 weeks depending on the product. Lead times vary by part, so quotes should be checked per part number.

How can firmware reduce the impact of a memory shortage?
Firmware decides how much RAM and flash a product asks for. Measuring real peak use per task, trimming safety margin that cannot be justified, and bounding queues and buffers in the design lets a product fit a wider set of memory parts, which gives procurement more alternates when one part goes long.

Should embedded products use an RTOS instead of Linux because of the memory shortage?
It depends on the product. ByteSnap suggests considering an RTOS in place of Linux to reduce memory footprint where the product allows it. The decision should rest on the product's measured need, not on the shortage alone.

Labels: Opinion 45% · Experience 20% · Fact 35%. Written in collaboration with AI — I discuss, I do not outsource.

This is a Ritzy Lab wave note. If you ship connected devices and want to compare notes on designing for a tight parts market, the longer story and how I work live on my profile. — Ritesh | ritzylab.com

#EmbeddedSystems #Firmware #SupplyChain #EmbedIQ