Should Editors Keep Project Databases on the NAS or Only the Media?

Keep media on the NAS by default; place the project database there only when the editing application explicitly supports that network topology.

For solo editors and small post teams, the useful split is not “everything local” versus “everything remote.” Camera originals and shared graphics benefit from one authoritative NAS path, while project state needs low-latency writes, correct locking, and a tested recovery method. Cache and previews remain rebuildable. The boundary changes only when supported multi-user collaboration makes a database service—not a normal shared folder—the source of truth.

Assign each data role before choosing a location

This role split mirrors real post-production pipelines, where delivery is a series of controlled paths rather than one undifferentiated folder. A detailed example of tiered dailies and release paths shows why access and workflow stage should determine placement.

Choose one of three project-state topologies

Solo editor: keep the project file or application library on the workstation SSD, save versioned copies to the NAS, and point media references at a consistent share path. This removes the network from the save transaction while preserving centralized media.

Editors handing off, not editing simultaneously: store closed project packages in a controlled NAS handoff folder, but require the current editor to copy the active project locally and check it back in with a new version. A visible owner field prevents two people from diverging silently.

Concurrent team: use the application's supported collaboration server or database service and place its persistent state on storage designed for that service. Do not imitate collaboration by opening the same ordinary project file from two workstations.

Keep caches and backups out of the production path

Put render cache, waveform data, thumbnails, and temporary proxies on each editor's local SSD unless they must be shared. These files can create many small writes, consume NAS bandwidth, and are cheaper to regenerate than to protect.

Back up project state and irreplaceable source media independently. Snapshots help recover earlier NAS versions, but they do not replace an offline or separate-system copy. Database backups must use the application's supported export or dump method so a restored copy is internally consistent.

If the media share itself is unreliable, fix that dependency before centralizing more state. ZimaSpace's guide to application data and network-share reliability provides a useful next check for separating databases from bulk media.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validate the workflow with a forced interruption

1. Open the same test project from every supported workstation and confirm media paths relink consistently.
2. Save, autosave, render, and export while another client transfers media.
3. Disconnect one workstation during a test save and verify the documented recovery path.
4. Restore yesterday's project version and a sample source file to an isolated location.
5. Confirm a new editor can identify the active project owner without asking.

The design is sufficient when media stays authoritative, project saves survive a client or network interruption, and restoration does not depend on an editor's memory. Add a database service only for real simultaneous collaboration; stop centralizing when the application does not support the resulting write path.

FAQ

Can a project file be copied to the NAS for backup? Yes. A closed, versioned copy is different from opening the live project over a share. Test the copy by restoring it with representative media.

Should proxies live on the NAS? Only when sharing them saves more time than their network traffic and management cost. Local proxies are usually simpler for one editor.