What is the difference between a cloud library and a local working set?

Keep a large library within reach of focused workstations

A shared cloud library gives the team a common collection, while each workstation’s working set reflects the files used for its current tasks. Suite’s local cache connects those two scales: access shared files through a drive and plan local capacity around active work. This is a practical advantage over preparing a complete independent replica of the library on every machine.

Suite uses a local cache as part of its connected filesystem workflow. The right planning question is how much active work the device must support comfortably, alongside its operating system, applications and generated files. Suite’s cache guidance recommends SSD storage and, where possible, enough cache allocation for the project or media being used.

Plan a large library with a focused working set

Imagine a team with a 40 TB library. A particular person is assigned a 300 GB project, and the workstation has 1 TB of local storage. The library, project and disk are three separate measurements. None alone tells you the correct cache allocation.

The application might inspect much of the project, generate large temporary files or revisit only a small subset. Other projects may run on the same computer. The nominal 1 TB disk also contains the operating system and applications. This is a planning example, not a Suite capacity guarantee or benchmark.

Before allocating cache space, measure what is actually free and identify what else needs to grow during the task. The goal is to avoid trading a full library replica for a different local-capacity problem.

Draw a simple capacity ledger

Record four quantities for each representative workstation:

• Library scope: the total collection the user can access. This describes availability, not a requirement to hold every byte locally.

• Active project scope: the files involved in the current assignment, including dependencies that may be opened indirectly.

• Local product cache: space allocated to the storage client for retrieving and reusing data.

• Other local demand: application caches, previews, exports, temporary files and ordinary system needs.

Keep free-space headroom outside the planned allocations. Do not add nominal capacities together and assume the device can safely operate at that limit. Observe a representative session, including an export or processing run, before standardizing the setup.

Watch how the working set changes

A working set is tied to a task and time window. A researcher inspecting a handful of files, an editor switching between timelines and a job scanning a complete directory may have very different patterns even when all three access the same library.

Ask what changes between morning and afternoon, and between one assignment and the next. Frequent revisits make cache behavior relevant. A one-time complete scan has a different transfer requirement. Record first access separately from repeated access to avoid attributing all changes in responsiveness to one setting.

Keep capacity separate from offline availability

Having cached data is not the same as having an independently usable offline copy. Suite requires an internet connection. The cache should be planned as part of the supported connected workflow, not used as a reason to promise disconnected operation. See Suite’s offline-use explanation.

Turn the ledger into a pilot

Choose one workstation and one real task. Record available space before the session, after opening the project, after sustained work and after generating outputs. Capture any pauses or errors. Review whether the allocation supports the task while leaving the rest of the computer healthy.

This exercise gives a team a concrete basis for discussing file streaming: broad access to a shared collection, with local resources planned around actual work. It does not establish how every application will behave. Use the Suite deployment options below to evaluate that distinction in your own environment.