Post-production storage is a bandwidth problem wearing a capacity problem's clothing. A 4K or 8K edit suite does not just need somewhere to keep enormous files, it needs to stream many of them, at once, to multiple editors who all expect their timelines to scrub without a stutter. Build it like an ordinary file server and the first afternoon of several artists working on high-bitrate footage will expose every bottleneck you skipped. This is how we spec a media and entertainment storage server for UK studios and broadcast teams, built around sustained throughput and concurrent streams rather than the IOPS or archive-cost lens that suits other workloads.
Bandwidth and concurrency, not just capacity
The defining number in media storage is aggregate throughput under concurrent access. A single uncompressed or lightly-compressed 4K stream is demanding; 8K multiplies it; and a working studio has several editors each pulling one or more streams while a render node writes output and an ingest job lands new footage. The server must sustain the sum of all that traffic without any one timeline dropping frames, which is a very different target from the bursty, small-block IOPS that databases generate.
That shifts the whole design towards sustained sequential performance and a network that can carry it. Capacity still matters, because media files are huge, but capacity is the easy part. The hard part is guaranteeing that ten people scrubbing high-bitrate footage all get smooth playback at the same time, which means designing for the worst-case concurrent moment, not the average.
A tiered design: NVMe project tier plus nearline
The standard answer is two tiers. A fast NVMe project tier holds the footage currently being edited, delivering the sustained throughput active timelines need, while a large nearline tier of high-capacity drives holds everything not in active use at a far lower cost per terabyte. Editors work against the flash tier and the bulk tier sits behind it for completed and dormant projects, so you pay for speed only where it is needed and for cheap capacity everywhere else.
Moving projects between tiers, by workflow or automatically, keeps the expensive flash tier reserved for live work. This mirrors the tiering principle behind other storage builds but tuned for throughput per stream rather than transactional latency, and it is why an all-flash box is rarely the economical answer for a studio with a deep archive. Build the capacity tier from high-capacity drives and the project tier from fast flash in our SSD and NVMe range.
- •NVMe project tier: sustained throughput for the footage being actively edited
- •Nearline capacity tier: high-capacity drives for completed and dormant projects at low cost per TB
- •Move projects between tiers by workflow so flash is reserved for live work
- •Design for the worst-case concurrent moment, not the average load
The network is usually the real ceiling
In media, the network is where edits go to die. A single 10GbE link is comfortably saturated by a couple of high-bitrate 4K streams, so a busy suite needs far more: bonded 25GbE to the server as a baseline and 100GbE for the heaviest 8K and multi-artist workflows, with editors' workstations on fast links of their own. The server can have all the throughput in the world, but if the path to the editors is narrow, that is the bottleneck everyone feels.
Size the network to the aggregate of concurrent streams plus ingest and render traffic, build it redundant, and use server-grade adapters with offload, from our network cards range. Match the switch fabric to the same speed end to end, because a fast server behind a slow switch simply relocates the bottleneck and hides it from whoever is trying to work out why playback stutters.
Protecting irreplaceable footage
Original footage is frequently irreplaceable: a shoot cannot be re-run, and losing rushes is a project-ending event. So media storage needs both drive redundancy to survive disk failures and a genuine backup, ideally with an offsite or immutable copy, because redundancy keeps the server running but does nothing against deletion, corruption or a ransomware event encrypting the lot. The two must not be conflated, however tempting it is to treat a resilient array as safe.
On the large drives a media nearline tier uses, favour a layout that tolerates a second failure during the long rebuild a multi-terabyte disk requires, and keep the boot device on its own mirrored pair separate from the media pool. Pair the server with a backup strategy sized to the value of the footage, and the studio can lose a drive, or a building, without losing the work.
Putting a studio server together
For most UK post-production and broadcast roles this lands on a storage-dense chassis with an NVMe project tier, a large nearline tier of high-capacity drives, generous ECC memory to cache hot media, and a bonded 25 or 100GbE front end. The exact split between flash and capacity follows the size of the active project set versus the archive, and the network follows the number of concurrent editors and the resolution they work at.
We design these throughput-first storage servers, choosing the chassis, the tier split and the network to the studio's concurrent-stream reality, in our server configuration service, and where the archive is very large we build it out on dense platforms from the Dell storage range. The result is a server that keeps every timeline smooth on the busiest afternoon, not just when one editor is working alone.