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 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.