DaVinci Resolve project server: what it is and where a mount fits

A DaVinci Resolve project server is a database that several copies of Resolve connect to at once, so two or more editors can open the same project instead of passing a file back and forth. Blackmagic ships it as a separate free application, and the database engine underneath it is PostgreSQL, listening on the standard PostgreSQL port 5432.

The part people get wrong on the first attempt is what the database holds. It holds the project: timelines, bins, clip entries, colour grades, markers, and the names and paths of the media. It does not hold a single frame of footage. The footage sits on storage, and every workstation has to be able to reach that storage at the same path. Get that wrong and you have a shared timeline where the clips are all offline.

Local database versus project server

Resolve always uses a database. On a fresh install it makes a local one on the internal drive, and that is the "Local Database" you see in the Project Manager. One machine, one database, one editor at a time.

A project server replaces that local database with a networked one. You install DaVinci Resolve Project Server on a machine that stays on, it runs PostgreSQL, and every workstation adds that database as a remote connection using the host's IP address, the database name, and the login. From then on the Project Manager shows the shared library and any workstation can open a project in it.

The collaboration features that make this survivable are in the paid application. Blackmagic sells DaVinci Resolve Studio 21 at $295 as a one-time purchase (checked Aug 2026), and the multi user features listed on its product page are bin and clip locking, multi user timelines, update notifications, and built in chat. Locking is the important one: it stops two editors from writing the same bin at the same moment, which is the failure that used to corrupt shared projects.

What the server machine has to be

The project server is a database, so its demands are the opposite of an editing workstation's. It needs to be reliable and awake, not fast.

• A machine that is on whenever anyone might edit. A Mac mini, a small Linux box, or the NAS if it can run the software.
• A fixed IP address or a hostname that resolves the same way from every seat. A DHCP lease that changes on Tuesday is a room full of editors who cannot connect on Tuesday.
• A drive with its own backup. The database is small and it is the single point of failure for every project in it. Blackmagic's application has a backup function; schedule it and copy the output somewhere else.
• An unfiltered path on port 5432 between the workstations and the server. A firewall rule or a VPN that blocks that port is the most common reason a correctly configured connection times out.

Do not run the project server on an editor's workstation. It works, right up until that editor reboots for a plugin installer in the middle of someone else's session.

The media path is the part that breaks

This is where a shared Resolve setup succeeds or fails, and it has nothing to do with the database.

When Resolve stores a clip in a project, it stores a path to the file. Editor A adds a clip at /Volumes/Media/ProjectX/Day01/A001.mov. Editor B opens the same project. Resolve looks for that exact path on Editor B's machine. If Editor B mounted the same share as /Volumes/Media-1 because a stale mount was still around, or mapped it to a different drive letter on Windows, the clip is offline.

Three rules make that problem stop happening:

1. One share, one name, every machine. Agree the mount name before anyone opens Resolve, and do not let the operating system append a number to it.
2. Mount it as a volume, not as a sync folder. A folder that a sync client fills on demand can present a file that is not fully local, and Resolve will read it as a stall or a failure rather than waiting politely. A real mount behaves like a disk, which is the whole argument in what a real mount means for editors.
3. Keep the cache and gallery off the shared path. Optimised media, render cache, and the still store are per-workstation. Point each seat at its own fast local scratch and leave the share for source media.

Mixed platforms make rule one harder rather than impossible. macOS and Windows will never agree on path syntax, so Resolve's Media Storage mapping is how you reconcile them, and it has to be configured once per workstation with the same intent.

Bandwidth: what the database needs, what the media needs

The database traffic is tiny. Text records, a few kilobytes at a time, at human speed. A gigabit link carries a room of editors talking to the project server without noticing.

The media traffic is the whole load. A single 4K ProRes 422 HQ stream runs in the region of 200 MB/s, which is already more than a gigabit link can deliver. That is the number that decides your network, not the database. Two editors scrubbing full-resolution timelines will saturate 10 GbE between them, and the standard answer is to cut proxies, edit off those, and relink to the originals for the finish.

Sizing that link properly is its own subject, covered in Thunderbolt versus 10 GbE for editing and 10 GbE on a budget.

Where this beats Blackmagic Cloud, and where it does not

Blackmagic Cloud hosts the project library for you. No server to maintain, no port to open, and remote collaborators connect without a VPN. It is the right answer for a team spread across cities, and it charges per project library.

A local project server wins on three counts. It costs nothing beyond the machine, the footage never leaves the building, and the database sits on the same network as the media so latency is a non-issue. It loses on the fourth: someone has to own it. Backups, upgrades, and the Tuesday it stops answering are yours.

Both approaches still need the media problem solved separately. Neither the local server nor the cloud library moves a frame of footage; the only thing that puts the same file at the same path on every workstation is the storage underneath, and that is the layer a mount handles.

The order to build it in

Storage first, path second, database third. Stand up the share, mount it identically on every seat, open one clip from each workstation to confirm the path resolves, and only then install the project server and migrate a project into it. Teams that build it in the other order spend their first week debugging a database that was working the whole time.