Storage vendors talk to editors in a private language: NAS, SAN, block versus file, ZFS, ARC, egress, 10 GbE. Most of it is simpler than it sounds, and knowing what the words actually mean is the difference between buying the right box and buying the box with the best marketing page. This is the working glossary I wish someone had handed me when I started cutting off a network. It is grouped by what you are actually deciding (where the storage lives, how it is shaped, how footage gets to your machine, how it stays intact, and what it costs to leave), with the jargon defined in plain English and a real number attached to each one.
Where the storage lives: DAS, NAS, SAN #
The first three terms describe where your drives physically sit relative to your machine. DAS is direct-attached storage: a drive or an array plugged straight into one computer over a cable like USB, Thunderbolt, or SAS. It is the fastest and dumbest option. One machine, one set of drives, no network. NAS is network-attached storage: a small box full of drives with its own operating system that shares files to many machines over Ethernet. When you mount a Synology or a TrueNAS box and it shows up as a volume, that is a NAS serving files. SAN is a storage area network: a separate high-speed network (historically Fibre Channel, increasingly 25 or 100 GbE) that hands out raw block storage to servers, which then put a filesystem on top. SANs are what big broadcast facilities ran for years; they are expensive and complex because, as AWS puts it, block storage at that scale requires the SAN fabric and you pay for allocated space whether you use it or not (AWS, "block vs file vs object," checked Jun 2026).
The analogy: DAS is the external drive on your desk. A NAS is the shared fridge in the office kitchen, with shelves everyone can reach over the building's wiring. A SAN is the building's plumbing itself, raw pipes that other machines tap and finish however they like. For a one-to-five-person post team the honest answer is almost always NAS, occasionally DAS for a solo editor. SAN is rarely the right call anymore. If you are weighing actual hardware, our roundup of storage appliances for creatives in 2026 and the build vs buy guide for a small post house get specific.
How the storage is shaped: block, file, object #
These three describe the shape of the data, not where it lives, and editors trip over them constantly because cloud vendors use them loosely. File storage is the hierarchy you know: files inside folders, with a path. It is the friendliest and the one your NLE expects. Block storage chops data into fixed-size chunks (a few KB up to a few MB each) and stores them on disk optimized for fast, low-latency random access, with a filesystem layered on top to make sense of them (AWS, checked Jun 2026). It has the lowest latency and the least overhead, which is exactly why it matters for editing: you can read the middle of a 200 GB file without dragging the whole thing across the wire. Object storage keeps each file as a self-contained object with its metadata, addressed by a key rather than a folder path. It scales almost infinitely and is the cheapest per terabyte, but you generally cannot modify an object in place (you replace it), and writes are slower than block or file (AWS and IBM, checked Jun 2026). Amazon S3, Backblaze B2, and Wasabi are object storage.
| Shape | How it is addressed | Strength | The catch for editors |
|---|---|---|---|
| File | Folder path, e.g. /Projects/ClientA/render.mov | Familiar, what your NLE expects | Bottlenecks under many users and large files |
| Block | Fixed-size blocks, filesystem on top | Lowest latency, random access into big files | Underlies a SAN; raw blocks are not human-browsable |
| Object | Key plus metadata, no real folders | Cheapest per TB, scales endlessly | No in-place edits, slower writes, needs a layer to feel local |
Why this matters in practice: cloud editing tools that feel fast do block-level streaming on top of object storage in the background, fetching only the chunks you scrub to instead of the whole clip. The opposite is whole-file sync, where the entire file copies down before you can touch it. That single distinction decides whether remote storage feels like a local drive or like waiting for a download, and it is worth its own read in block-level streaming vs whole-file sync, explained with one analogy.
How your machine talks to it: SMB, NFS, and the mount #
Once footage lives on a NAS, a protocol carries it to your machine. SMB (Server Message Block) is the default on macOS and Windows; the modern version, SMB3, adds encryption (AES-128-GCM or AES-256) and SMB Multichannel, which lets one session use several network adapters at once to aggregate throughput on 10 Gb-plus links (Visuality Systems and Windows Forum, checked Jun 2026). NFS (Network File System) is the Unix-native protocol; it often wins on small-file and random-read workloads by double-digit percentages, while large sequential reads land within a few percent of SMB (windows-centric vs unix-centric, both protocols, checked Jun 2026). Most NAS boxes run both, and the common pattern is SMB for editor seats and NFS for Linux render nodes.
A mount is the act of attaching that remote share so it appears as a volume in Finder or Explorer with a drive letter or path. The phrase you will hear is "a real mount," meaning the storage behaves like a local disk (you can scrub, open, and save in place) rather than a sync folder that hides a copy-down step. The distinction is the whole topic of what a real mount means for editors, and it is the line between SMB-over-the-LAN feeling instant and the same share crawling once you put a VPN in front of it. One honest note on terminology: a mount is a transport, not magic. If the underlying link or the NAS is slow, the mount is slow.
The pipe: GbE, Thunderbolt, throughput, and IOPS #
Network speed is quoted in gigabits per second, written GbE (gigabit Ethernet). The gotcha that catches every editor once: bits are not bytes. Divide the gigabit number by eight, then knock off overhead, to get the megabytes per second you actually feel. So 2.5 GbE delivers roughly 250-280 MB/s real-world, and 10 GbE tops out near 1,100 MB/s but realistically lands around 939 MB/s on a clean link (Larry Jordan and 2.5GbE guides, checked Jun 2026). Thunderbolt is a direct-attach pipe, not a network: Thunderbolt 5, shipping in creator and workstation machines through 2025, runs 80 Gbps bidirectional and boosts to 120 Gbps for display-heavy traffic using PAM-3 signaling (Intel newsroom, checked Jun 2026). That is why Thunderbolt is the king of single-machine DAS and 10 GbE is the workhorse for shared NAS access. The tradeoff is its own piece: Thunderbolt vs 10 GbE for editors.
Two more pipe words. Throughput (or bandwidth) is how much data per second the link moves, the number that matters for streaming big sequential video files. IOPS is input/output operations per second, the count of small separate reads and writes, which matters when many editors scrub many clips at once or when a project file pokes at thousands of tiny assets. A drive can have great throughput and poor IOPS or the reverse, and editing needs both: throughput to stream the master, IOPS to keep a busy timeline responsive. For building the rest of the network around the pipe, see the network reference build for a 2 to 5 person post team.
The filesystem and integrity: ZFS, RAID, parity, scrub, bit rot #
ZFS is the filesystem most serious NAS boxes run (TrueNAS, QNAP QuTS hero, most build-your-own). Its headline trick is catching bit rot, the silent corruption where a stored bit flips and a normal drive hands you the bad bytes without noticing. ZFS checksums every block it writes and verifies it on every read, so it detects corruption instead of serving you a glitchy frame, and in a redundant layout it repairs the bad block from a good copy (OpenZFS docs, checked Jun 2026). A scrub is the scheduled pass that reads the whole pool and verifies those checksums; run one monthly. RAID (redundant array of independent disks) is the broader idea of combining drives so the array survives a failure. Parity is the math that makes that possible without keeping a full second copy: RAIDZ1 survives one drive failure, RAIDZ2 survives two. Mirrors keep full copies instead, costing half your capacity but giving far better IOPS for busy edit work.
Two ZFS terms you will see on cache pages. ARC is the read cache that lives in RAM and is the single biggest reason a well-specced ZFS box feels fast; L2ARC is an SSD second tier for blocks that overflow ARC, useful but not free because it needs RAM to index. One genuinely good 2025 development: OpenZFS 2.3 shipped RAIDZ expansion in January 2025, so you can finally add a single drive to an existing RAIDZ array without rebuilding the pool (Phoronix and The Register, Jan 2025, checked Jun 2026). If any of this is the deciding factor in your build, the plain-English deep dive is ZFS for video editors, explained plainly.
Cache, proxies, and the cost of leaving: egress and lock-in #
A cache is a small, fast copy of data kept close to where it is used so you do not pay the full trip every time. In editing it shows up two ways: the read cache in RAM (ARC) on the NAS, and a local SSD cache on your machine that a good mount layer keeps full of the chunks you are actively scrubbing, so a clip you have touched plays instantly the next time. A proxy is a different idea often confused with cache: a low-resolution stand-in copy of your footage (smaller codec, lower bitrate) that you cut with and then relink to the originals at export. Caches speed up access to the real file; proxies replace the real file with a lighter one. Sizing the cache is genuinely worth getting right, covered in sizing your SSD cache.
Finally, the cost word that surprises everyone: egress, the fee a cloud provider charges to move your own data out. This is where cloud storage bills hide. Amazon S3 charges $0.09/GB for the first 10 TB of internet egress each month after a 100 GB free tier (AWS S3 pricing, checked Jun 2026). Backblaze B2 is friendlier, giving free egress up to 3x your average monthly storage and $0.01/GB beyond, with unlimited free egress through CDN partners like Cloudflare and Fastly (Backblaze, checked Jun 2026). Egress is the financial half of lock-in: the more it costs to pull your library out, the harder it is to leave a platform. We put real numbers on that in your bytes are your bytes, what leaving actually costs and break down object backends in B2 vs Wasabi vs S3 as a media backend.
Sources, checked June 2026
- AWS, Block vs File vs Object Storage: definitions of block, file, and object storage, latency and overhead characteristics, SAN cost model.
- IBM, Object vs File vs Block Storage: object metadata, no in-place modification, slower writes.
- Visuality Systems and Windows Forum, SMB vs NFS comparisons: SMB3 encryption, SMB Multichannel, NFS vs SMB performance on small-file and sequential workloads.
- Larry Jordan and 2.5GbE/10GbE explainers: real-world throughput of 2.5 GbE (~250-280 MB/s) and 10 GbE (~939 MB/s), bits-vs-bytes conversion.
- Apple ProRes white paper and ProVideo Coalition, data rates: ProRes 4K 422 HQ ~1,485 Mbps (~186 MB/s), ~2x codec rate rule of thumb.
- Intel Newsroom, Thunderbolt 5 standard: 80 Gbps bidirectional, 120 Gbps Bandwidth Boost, PAM-3 signaling, 2025 availability.
- OpenZFS documentation: per-block checksums verified on read, self-healing from redundancy, scrub behavior, ARC and L2ARC.
- Phoronix and The Register, OpenZFS 2.3 (January 2025): RAIDZ expansion to add a single drive to an existing array.
- AWS S3 pricing page: $0.09/GB internet egress for the first 10 TB after a 100 GB free tier.
- Backblaze B2 pricing and developer pages: free egress up to 3x average monthly storage, $0.01/GB beyond, unlimited free CDN egress via partners.