Workstation Scratch vs Shared Scratch Tier for Post-Production: Which Files Should Teams Share?

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Keep media cache and other workstation-specific, latency-sensitive files on local SSD or NVMe. Use a shared scratch tier for previews, auto saves, proxies, temporary renders, or project assets only when another editor or render system will reuse them. The correct split depends on whether the file is disposable, shareable, expensive to recreate, and safe for concurrent access.

Workstation Scratch vs Shared Scratch at a Glance

Local scratch is optimized for one workstationโ€™s response time. Shared scratch is optimized for reuse and collaboration. Moving every temporary file to the NAS creates unnecessary network traffic; keeping every generated file local can force several editors to repeat the same render or proxy work.

Scratch category Better default Decision reason
Media Cache and cache database Workstation SSD or NVMe High-frequency, workstation-specific access
Audio conform and peak files Usually local Rebuildable and latency-sensitive
Preview files Shared when several editors reuse them Can avoid repeated rendering inside one Production
Auto Save Shared project location plus independent backup Recovery should not depend on one workstation
Proxies Shared for team reuse; local for one editor Large but reusable across systems
Temporary exports and renders Depends on downstream reuse Share only when another system consumes them

Why Should Media Cache Usually Stay Local?

Media Cache contains accelerator files and a database that the editing application accesses repeatedly. Adobe recommends a fast SSD or NVMe location and specifically advises keeping Media Cache local in shared environments. The files are rebuildable, so central protection provides less value than low-latency access.

Adobeโ€™s current Media Cache guidance describes peak and conformed audio files as accelerator data and recommends clearing old or unused entries. A shared tier turns this disposable workload into network traffic and a cleanup problem.

Local cache also isolates workstation behavior. One editor can clear or rebuild cache without affecting another. If cache must be moved, dedicate a local volume with enough free space and monitoring rather than placing it beside protected source media.

When Does Shared Scratch Save Team Time?

Shared scratch is valuable when the generated output is reusable. Preview files rendered by one editor may allow another editor to play the same section without repeating the render. Shared proxies can also prevent several workstations from creating identical lightweight media.

Adobeโ€™s Productions scratch settings place scratch folders beside the Production by default and allow teams to select a shared location. This applies to shareable Production outputs, not to the separate Media Cache recommendation.

The value depends on reuse. A preview generated once and consumed by several editors saves compute and time. A temporary render used by one workstation creates more network writes, retention questions, and naming conflicts than value.

Which Scratch Files Must Survive a Workstation Failure?

Auto saves should not disappear with the editing workstation. They belong beside a protected project location or another recovery target accessible after a workstation failure. They are temporary versions, but their recovery value is high when the current project becomes corrupted or an editor makes a destructive change.

Proxies may also deserve protection when they are expensive to regenerate or remote editors depend on them. They do not replace camera originals, but losing a large proxy set during a deadline can create substantial downtime. Retain them according to production cost rather than treating every proxy as disposable.

The ZimaSpace guide to Premiere NAS storage placement provides the broader file-role map. This comparison focuses on the narrow decision of which generated files should be shared between post-production systems.

Which Tier Handles Concurrent Writes Better?

Local NVMe isolates heavy cache and conform writes from the network. Each workstation receives predictable scratch performance, and one editor cannot saturate the shared tier while rebuilding cache. The cost is duplicated capacity and repeated generation across systems.

A shared scratch tier must handle concurrent previews, auto saves, proxy creation, and temporary renders without delaying source-media reads. NVMe can provide useful IOPS, but the NAS CPU, protocol, network uplink, and client links must sustain the complete mixed workload.

The existing NAS NVMe workload comparison explains why NVMe helps concurrent, latency-sensitive tasks more clearly than simple sequential media storage. It does not make an undersized network or overloaded NAS disappear.

Which Workflow Fits Each Post-Production Team?

Choose Workstation Scratch When

Keep scratch local when one editor uses the generated files, timeline response matters most, and the data can be recreated. Media Cache, cache databases, audio conform files, and individual temporary exports usually fit this model.

Choose Shared Scratch When

Use shared scratch when previews, proxies, auto saves, or renders are reused by several editors, render nodes, or finishing systems. Apply project-level folder rules, quotas, cleanup ownership, and snapshots where recovery value justifies them.

Use a Split Scratch Design When

Most teams should split the workload: local NVMe for cache and workstation-specific temporary files, shared SSD or NVMe for reusable previews and proxies, and protected HDD or SSD storage for source media and project masters. A ZimaCube 2 can host the shared tiers while workstations retain local cache.

Scratch-Tier Rules Before You Deploy

  • Classify every generated file as local-only, team-reusable, recoverable, or disposable.
  • Keep Media Cache and cache databases on fast local storage.
  • Share previews or proxies only when multiple systems will reuse them.
  • Put Auto Save on a protected location that survives workstation failure.
  • Set quotas and cleanup ownership for every shared scratch folder.
  • Measure shared-tier performance while media reads and proxy jobs run together.
  • Do not count scratch as a backup of source media or final projects.

FAQs

Can Premiere Preview Files Be Shared?

Yes. Adobe Productions can keep scratch locations, including preview files and Auto Save, on shared storage so collaborators can access them. The network and storage tier must support the resulting writes, and the team needs a cleanup policy.

Should Proxies Stay Local?

Keep them local when only one editor needs them or remote work requires a portable copy. Share them when several editors use the same proxy set and regenerating them repeatedly costs more time than storing and serving them centrally.

Is Shared Scratch a Backup?

No. Scratch is an operational workspace. Some files may be worth snapshotting for short-term recovery, but source footage, project files, databases, and final deliverables require independent backups with defined retention and an offsite copy.

Final Verdict

Keep workstation-specific cache and conform data local. Share previews, auto saves, proxies, or temporary renders only when another editor or system will reuse them. A disciplined split gives editors local responsiveness while preventing the team from rebuilding the same expensive outputs on every workstation.

Product Comparisons

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.