Game development produces an unusual storage profile: enormous binary files that change constantly, a build system that manufactures hundreds of gigabytes of throwaway output every night, and artists who will notice a fifty-millisecond latency increase before any monitoring dashboard does. A 120-person studio shipping cross-platform routinely runs 300 TB to a petabyte.
None of it behaves like the enterprise file workloads vendors usually benchmark. There is no meaningful dedupe on compressed textures, no quiet window for maintenance during crunch, and no tolerance for a slow build farm two weeks before certification submission.
Perforce Depots and the Large Binary Problem
Most studios still run Perforce because it handles multi-gigabyte binaries with file-level locking in a way Git fundamentally does not. The depot is the crown jewel, holding every version of every source asset, and it grows monotonically because artists rarely obliterate history.
Depot storage has two components. The versioned archive is a huge tree of revision files, mostly large and written once. The metadata database is tiny but latency-critical, since every sync and submit across the studio hits it. Splitting those across tiers, with metadata on NVMe and the archive on high-capacity NAS storage solutions, is the most effective tuning change available, and it is frequently overlooked because both live under one server.
Per-Platform Build Output Adds Up Fast
A title targeting PC, two console generations, and a streaming variant produces four to six build outputs, each with debug, profile, and shipping configurations. Uncooked plus cooked content for a modern build lands anywhere from 80 GB to 400 GB per platform per configuration.
Nightly across all targets, that is easily 1 to 3 TB of new artifacts. Add per-changelist CI builds and studios often find the build archive is larger than the source depot. These artifacts are already compressed and packed, so they deduplicate poorly and no reduction ratio will rescue you.
The answer is a pruning policy enforced by automation. A common pattern keeps every build for seven days, one per day for thirty days, one per week for a quarter, and permanent retention only for milestone, submission, and shipped builds. That converts unbounded growth into a predictable steady state.
Artist Workstation Throughput Is the Real Test
When an environment artist opens a level, the workstation pulls thousands of files: meshes, 4K and 8K textures, materials, and cached lighting. A single scene load can move 10 to 30 GB. Ten artists doing that at 9:05 in the morning is a 300 GB read burst.
This is where studios feel the gap between adequate and good NAS storage solutions. The failure mode is not an outage but a slow creep: level load goes from 90 seconds to four minutes, artists take coffee breaks during loads, and departmental productivity quietly drops. Nobody files a ticket because nothing is broken.
Instrument it. Track editor load times alongside array latency, and run 10 or 25 GbE to the workstations handling the heaviest scenes. Size against the morning read burst, not daily average throughput.
Shader and Derived Data Caches
Compiling shaders and cooking derived data is expensive, so engines maintain caches that can be shared studio-wide. A shared derived data cache turns a 40-minute first-run compile into a two-minute download for everyone after the first developer, which on a large team reclaims a lot of engineering hours.
The catch is the access pattern: millions of small files, high read concurrency, heavy metadata operations. It is the opposite of the large-file streaming profile the rest of the studio generates, and few NAS storage solutions do both well without deliberate tuning. Engineers new to this should understand what is NAS capable of in mixed small and large file environments, because a shared cache exposes weak metadata handling immediately. Give it its own share, cap its size, evict least-recently-used, and treat it as disposable.
Playtest Video and Telemetry Capture
Structured playtesting generates video. Screen capture at 1080p60 for a two-hour session is 15 to 30 GB, often with facecam and audio alongside. Twenty testers a week produces 600 GB to 1.2 TB of footage that designers genuinely watch.
Telemetry is smaller but more queried. Event streams recording every death, menu open, and dropped frame, joined to build version and hardware profile, become the dataset the design team leans on for balance decisions. Keep telemetry indefinitely since it is small and compounds in value. Keep raw video for the current milestone and clipped highlights permanently.
Remote Artists and Latency
Distributed teams changed the conversation. Perforce proxies at remote sites cache read-heavy content near the user and cut sync times, but they do nothing for submits, which still traverse the WAN to the master.
For heavy content creation, many studios concluded that shipping pixels beats shipping files: remote workstations sitting next to the storage, accessed over a low-latency remote desktop protocol. It costs more per seat, but a remote artist syncing 200 GB over a home connection loses a working day, and it recurs after every large content merge.
Protecting Work Through Certification and Patch Cycles
The window between content lock and release is when data loss would hurt most and the team has the least slack. Certification requires reproducing exact builds, and patches require diffing against the shipped build to keep download sizes small. Losing the shipped archive means shipping full downloads instead of deltas.
Studios treating NAS backup as an afterthought discover during a real incident that their depot checkpoint and archive snapshot were taken hours apart and no longer reconcile. Cover the depot archive, the metadata database, and milestone artifacts as one consistent set with an immutable offsite copy, snapshot them together, and verify a restore quarterly.
The Bottom Line
Studio storage comes down to four decisions: split Perforce metadata from the archive, enforce automated build pruning, size against the morning artist read burst rather than daily averages, and protect the depot and milestone builds as one consistent immutable set. Handle those and storage stops being something the team notices, which is the only outcome a technical director actually wants.
Top comments (0)