Sizing your SSD cache: how much do you actually need for editing?

Size your SSD cache to the working set of your current project, not to the whole library. That one sentence saves most editors a few hundred dollars, especially now: NAND prices spiked through early 2026, so the gigabytes you cache cost real money again. A cache holds the blocks you are actually touching right now, so it only has to be big enough for the footage in your active timeline plus a little headroom, not big enough to mirror every terabyte on the NAS.

What a cache actually is (and what it is not) #

A read cache is a fast local copy of the bytes you read most recently. When you scrub a clip off a network volume, the data lands on your local SSD on the way to the player. Scrub the same clip again and it comes off the SSD instead of crossing the wire, so it feels instant. The cache is not a sync folder and it is not a backup. Nothing lives there permanently. When it fills up, the oldest, least-touched blocks get thrown out to make room for new ones. Think of it like the counter space in a kitchen: you do not need counter space for every ingredient you own, only for the ones you are cooking with tonight. The pantry (your NAS) holds everything else.

This matters for sizing because it flips the intuition. People assume a cache should be a fraction of total storage, like a tenth of a 40 TB library. It should instead be a multiple of one thing: the footage you can have open and busy at once. JuiceFS, the open-source file system JuiceMount is built on, ships with a 100 GiB default cache size and evicts with an algorithm similar to LRU (least recently used), dropping the coldest blocks first (JuiceFS docs, checked Jun 2026). That 100 GiB default is a starting guess, not a recommendation for your workflow. The right number comes from your codec and your timeline.

Working-set thinking: the only number that matters #

Your working set is the total size of the media your edit reaches for during a session: the clips on the timeline, the bins you keep flipping through, the B-roll you are auditioning. It is almost never your whole library. On a typical commercial or short-form job, you might be cutting from 2 to 6 hours of source footage even if the project folder holds 50. That active slice is what the cache needs to hold.

The size of that slice is driven entirely by your codec's data rate. Higher-quality codecs eat more bytes per second, so the same one hour of footage can be 66 GB or 318 GB depending on what you shot and whether you transcoded. Here are the rates worth memorizing, converted to gigabytes per hour of footage so you can do the math in your head.

Read that table as a shopping list. If you cut camera-native H.265 from a mirrorless body, three hours of working set is under 300 GB, and a small cache covers it easily. If you transcode everything to 4K ProRes 422 HQ, three hours is roughly a terabyte, and the same cache will thrash. The codec decision you made on import is the single biggest lever on the cache size you need. ProRes and Blackmagic RAW data rates are published by Apple and Blackmagic Design respectively (checked Jun 2026); H.265 mirrorless rates from Sony, Canon, and Panasonic bodies land in that 60-200 Mbps band.

Hit rate is the thing you are actually buying #

A cache pays off only when you read the same data more than once, and editing is one of the most repetitive read patterns there is. You scrub the same hero shot forty times. You loop a section while you tune a transition. You bounce between the same six clips for an hour. Every one of those repeat reads is a cache hit if the block is still local, which means it never touches the network. The metric that captures this is hit rate: the percentage of reads served from local SSD instead of the NAS.

Here is the part most sizing guides miss: hit rate does not climb smoothly with cache size. It hits a cliff. Below the size of your working set, you are constantly evicting blocks you are about to need again, so the hit rate stays low no matter how much you scrub. Cross the working-set threshold and the curve snaps up to near the ceiling, because everything you touch stays resident. Buying cache beyond that point buys you almost nothing, which is exactly why oversizing wastes money. You want to land just past the knee of that curve, not far up the flat part.

A simple sizing method #

Here is the method I give people, and it takes about two minutes with the table above.

First, estimate hours of active footage. Not the project total: the footage you genuinely flip through in a working day. For most jobs that is 2 to 6 hours. Second, multiply by your codec's per-hour figure from the table. Third, add 50 percent headroom so the cache is not running at the edge of eviction, where it starts dumping blocks you still want. The formula is: cache size = active hours x GB per hour x 1.5.

A worked example. You are cutting a 4-hour working set of camera-native H.265 at roughly 70 GB per hour. That is 280 GB of working set, times 1.5 is 420 GB. A 512 GB cache partition is plenty. Now the same 4 hours transcoded to 4K ProRes 422 HQ at ~318 GB per hour is 1,272 GB of working set, times 1.5 is about 1.9 TB, so you want a 2 TB cache. Same edit, same hours, nearly 4x the cache requirement, entirely because of the codec. If your number lands awkwardly between drive sizes, round up to the next common capacity rather than shaving it close.

Two adjustments. If you work in proxies (and at 4K, transcoding to a fast appliance or cutting against proxies is usually the smarter move than streaming full-res HQ), use the proxy row of the first table, around 20 GB per hour, and your cache requirement collapses. If you are a multi-editor shop where everyone hammers the same shared project, each workstation still only caches what that editor touches, so size per seat, not per team.

What it costs in 2026, and why undersizing is cheaper than you think #

This is the year to be disciplined about cache size, because SSDs are not cheap right now. TrendForce projected client SSD contract prices rising at least 40 percent quarter over quarter into Q1 2026 on the back of AI data-center NAND demand, and the street prices show it: the Crucial T500 2 TB Gen4 drive swung from a low near $23 in late 2025 to a peak around $678 in May 2026 before settling back into the low-to-mid hundreds by mid-2026 (Pangoly and camelcamelcamel price histories, checked Jun 2026). When a 2 TB cache drive can cost as much as a used camera body, the difference between a right-sized 512 GB cache and a reflexive 2 TB one is real money, not a rounding error.

The good news is that undersizing degrades gracefully. A cache that is a little too small does not break anything. It just lowers your hit rate, so a few more reads cross the network. With a sane LAN and the right transport, that is invisible most of the time; it only stings on a cold cache or a sudden jump to footage you have not touched (and if it stings badly, the culprit is often the network path, not the cache, which is its own slow-NAS checklist). Compare that to undersizing RAM or a boot drive, where you hit a hard wall. A cache that is too small is a soft, tunable cost.

One practical knob: keep the cache on a dedicated SSD or partition, not your OS drive. JuiceFS recommends a high-performance dedicated disk for the cache directory and warns against sharing it with other applications, and it holds back 10 percent of free space by default (the free-space ratio) so the disk never fills to zero (JuiceFS docs, checked Jun 2026). If you want to understand why a local cache beats dragging whole files around, that tradeoff is covered in block-level streaming versus whole-file sync.