feels local, with receipts
Storage that scales, but feels local.
Editing lives on latency: the bin that opens the moment you click, the scrub that answers under your finger, the search that returns before you finish typing. JuiceMount keeps all three on your Mac (metadata in local SQLite, blocks on local SSD) and pays the network only for what you haven't touched yet. This page is every performance number we publish, how each was produced, a plain list of what they don't prove, and two demos you can drive.
- 15–120 ms directory open on a 100 K+-entry volume (3–10 s through raw FUSE)
- ~29 ms filename search across ~131 K entries
- 226–571 MB/s cached reads through the full NFS path
- 4–67 ms un-pinned read refusal in offline mode
- ~7 Gbit/s and when data does move: sustained on a 10 GbE LAN, up and down (author-measured)
Every number on this page was measured by the author on his own setup: an Apple-Silicon Mac ↔ TrueNAS SCALE over 10 GbE. Honest measurements, not marketing benchmarks; your hardware will differ. Methodology, workload scripts, and the regression harness are public.
demo 01 · scrub the wire
Drag the playhead. Watch what caches.
One hypothetical 100 GB clip, drawn twice: the strip your NLE shows you on your Mac, and the ~4 MB blocks it lives in on your NAS. Scrub the strip, and the blocks you touch page in over the dashed lines, land in the SSD cache row, and stay there. Then switch models and watch what a whole-file sync tool has to move instead.
A001_C002_0212RM.braw100 GB
Move the playhead. Only the blocks under it page in.
Drag anywhere on the strip, or Tab to the playhead and use the arrow keys; Home/End jump, PageUp/PageDown step by ten.
Illustrative model of block-level paging: 80 cells stand in for a real clip's ~25,000 blocks of ~4 MB, and the wait math uses link line rate (first reads are bounded by your link). The cache row persists on purpose: a block pages in once and stays. Real numbers: 226–571 MB/s cached reads, author-measured, in the table below, and the methodology.
UI mock: the frame cells are placeholders and the clip name is invented; the paging behavior is the product.
demo 02 · the same minute, two mounts
One minute of editing, two ways.
Six ordinary moves: open a bin, scrub a clip, open another bin, scrub again, revisit the first clip, search the library. A plain SMB share pays the wire a round trip for every touch, every time. JuiceMount pays it once for each new block, then answers from your SSD; the cache keeps the files you're working on local and current.
- Open the project bin2,400 items
- Scrub the hero clip12 touches · ~48 MB
- Open the B-roll bin2,400 items
- Scrub a B-roll clip8 touches · ~32 MB
- Back to the hero clipthe same 12 spots
- Find one clip by name~131 K entries
Press play. The beats are paced for reading; the clocks and counters land on the model's honest totals.
Illustrative model, labeled: the SMB lane is a category sketch (one round trip per 100 directory entries, no persistent client cache, no library index) not a benchmark of any vendor's NAS or client. Round-trip times and link speeds (0.5 ms/125 MB/s LAN, 20 ms/12.5 MB/s VPN, 60 ms/6.25 MB/s road) are assumptions you pick, not measurements. The JuiceMount waits are the author's measured figures at their slow ends (directory opens 15–120 ms, library search ~29 ms, cached reads 226–571 MB/s) and its first-touch scrubs pay the same wire as anything else, once. Category behavior as of June 2026.
Editing from home or the road for real: remote routing is one Tailscale away. See the setup guide.
Plain-words companion: why your NAS feels slow over a VPN.
UI mock: the bins, clips, and touch counts are invented; the round-trip accounting is the point.
the physics · plain words
Local speed on site, cached speed away
A cloud mount can never be faster than your internet connection; at the studio or anywhere else, every byte arrives through the line your ISP sells you. A NAS in your building talks over your LAN, and that's where the measured ~7 Gbit/s lives. Away from the studio, JuiceMount rides the same internet as everything else, behind a cache that already holds the blocks you've been working with, so most of what you do never touches the wire at all.
Off site, nobody beats the physics, which is why the cache does the heavy lifting there, and why every vendor in this category now runs one on hardware you supply (below, with sources).
the cache · nine hits, one miss
What the cache does to the wire
A hit answers from your SSD and never touches the wire; a miss crosses it once, then stays cached. The receipts, author-measured: cached reads run 226–571 MB/s through the full NFS path, READ p95 481 µs; the fully-cached 200 MiB sequential read did 431 MB/s with 4.6 MB total network traffic; with the network off entirely, a pinned 350 MB file read at 215+ MB/s sustained.
Illustrative model, not a measurement: nine reads answer from local SSD, the one miss crosses the wire once and stays cached after. The chart below is the measured receipt.
the industry agrees · checked 2026-06-11
Their answer to latency is your hardware
Every storage SaaS in this category has shipped the same fix for WAN latency: a cache running on hardware the customer supplies. We agree with all of them: a local cache on hardware you own is the answer. We differ on charging rent on top of it.
Point the client cache at your own SSD or NAS
A whole studio can share one cache box. Suite requires SSD, not HDD, and publishes a shopping guide for cache drives to buy. Listed as a feature of the $75/TB-month Managed plan; the hardware is yours.
Runs on your Mac, a Linux box, even your TrueNAS
Bridges your on-prem storage to their cloud, and ships packaged as a TrueNAS app. Standard ISG appears included with iconik plans; ISG Pro is a quote-only add-on.
"A commodity on-prem server with SSD storage"
Their words: you supply the server, they advise on specs. Enterprise-only, early release, quote-only. Connect (announced March 2026) mounts S3 buckets you already have; also Enterprise-gated.
Block cache and offline pinning on your own disk
ShadeFS caches blocks and pins whole files for offline work, built into the client, living on storage you provide.
Sources, all checked 2026-06-11
- Suite "Onsite Caching": suitestudios.io/pricing (listed as a Managed-plan feature); support.suitestudios.io articles 8022828 (how the cache works), 8208172 (pre-caching), 8780699 ("Best cache drives to buy"); blog.suitestudios.io, on-prem hybrid workflow post.
- Iconik Storage Gateway: help.iconik.backlight.co article 25304282498327 (ISG overview); apps.truenas.com/catalog/iconik-storage-gateway; iconik.io/pricing (ISG Pro listed as an add-on, no published price).
- LucidLink TeamCache: lucidlink.com/teamcache ("a commodity on-prem server with SSD storage"; Enterprise early release, "talk to us to enable"). LucidLink Connect: blocksandfiles.com 2026-03-10; siliconangle.com 2026-03-05 (Enterprise plans only, no published price).
- Shade: academy.shade.inc/shadefs/pinning-files-offline; academy.shade.inc/shadefs/managing-the-shadefs-cache.
- Full facts pack with URLs and contradictions flagged: docs/web/RESEARCH_ROUND2.md §3 in the repo.
the ledger · canonical numbers
Every number we publish
This table is the page's one home for the measured figures; the README carries the same one, kept in sync by hand. One shared caveat: measured by the author on his own setup; your hardware will differ.
| What | Measured |
|---|---|
| Sustained network throughput, 10 GbE LAN | ~7 Gbit/s up and down (author-measured) |
Cached read through the full NFS path (dd, 200 MiB) |
226–571 MB/s, READ p95 481 µs |
| Fully-cached 200 MiB sequential read | 431 MB/s with 4.6 MB total network traffic |
| Pinned 350 MB file read, network off | 215+ MB/s sustained |
| Directory open, 100 K+-entry volume | 15–120 ms (3–10 s through raw FUSE) |
| Filename search across ~131 K entries | ~29 ms |
| Un-pinned read refusal in offline mode | 4–67 ms (vs. a 30 s NFS retry hang) |
Context for the throughput row: on the same 10 GbE link, Mountain Duck/Seafile-class mounted-bucket tools measured ~0.8–1 Gbit/s in the author's testing, bound by single-stream sync engines, not the network. Category behavior as of June 2026; check current client docs, these tools evolve. At 10 GbE the remaining ceiling is honest physics: disks, single-link line rate, and protocol overhead.
methodology · public harness
How the numbers were produced
The rig: the author's Apple-Silicon Mac ↔ TrueNAS SCALE over 10 GbE. The instrument: the repo's own performance harness, the same battery that gates releases.
- Workloads model real NLE and Finder behavior, not synthetic IO:
resolve-scrubsustains the ~60–240 random READs/sec a DaVinci scrub generates;finder-copy-deepruns Finder copy cascades with AppleDouble sidecars;bin-browsewalks directory trees the way a bin browser does;cold-playbackreads fully-uncached files sequentially;pin-coverage-verifyre-prefetches an entire pin root. - Each run snapshots the control plane's
/metricsbefore and after a fixed wall-clock window (typically 30–60 s) and emits per-RPC latency percentiles (p50, p95, p99, max) plus throughput deltas. That's where figures like READ p95 481 µs come from. - Baselines are stored per build SHA, and a regression orchestrator fails any build where an RPC type's p95 doubles or throughput halves against baseline. Workloads are re-run under chaos (Redis flaps, throttled MinIO, forced metadata syncs) to surface the next latent bug class, not to flatter the numbers.
The full contract (workload scripts, thresholds, baseline lifecycle) is published in docs/PERFORMANCE_METHODOLOGY.md; the scripts live in the repo under scripts/qa-suite/.
scope
What we don't claim
This is not a benchmark of named competitors' current builds. The sync-tool figure in the ledger is what Mountain Duck/Seafile-class tools measured in the author's testing, on his rig, at the time; and the SMB lane in demo 02 is an illustrative category model, not a measurement of anyone's NAS. Category behavior as of June 2026; check current client docs, these tools evolve.
These are point-in-time author measurements on one Mac and one NAS, not independent benchmarks. No vendor lab, no tuned showcase, and no claim beyond what the harness reproduces. The two demos on this page are illustrative models built on these measurements plus link line-rate and round-trip arithmetic, and they say so where they say anything.
Your rig will differ. Run it yourself.
The harness compares any two builds on your hardware, and a report from a different NAS, switch, or NLE is a genuinely useful contribution, whether it beats these numbers or not.