Using Project Manager in a Team: A Practical Guide to Setting Up a Shared Database

A step-by-step guide written for 3D artists — clear enough to follow without a sysadmin, accurate enough that one wouldn’t wince.

You work in a studio, and every artist keeps their own separate library of tags, collections, comments, and ratings. Someone tidies up a catalogue — nobody else sees it. Sound familiar?

Project Manager solves this by switching from a local database (SQLite, just for you) to a shared database (MySQL or MariaDB, used by the whole team). One person organises an asset, tags it, rates it — and everyone sees it.

Do you actually need this? A shared database only makes sense when two or more people work with the same library at the same time. If you’re a solo artist — or the only one touching the library — stay on the default local database. It’s faster to set up, needs no maintenance, and a server would just add moving parts for no benefit. This guide is for teams sharing one library concurrently.

How the pieces fit together

A lot of confusion disappears once you can picture the setup. There are three separate things:

   Artists' PCs  (3ds Max + Project Manager)
        │   ← tags, catalogues, ratings, comments
        ▼
   Shared MySQL / MariaDB server   ← the catalogue (metadata only)
        
   Shared NAS / network drive      ← the actual model & texture files

The database stores the organisation — tags, catalogues, ratings, comments, folder structure. It does not store, move, or copy your model and texture files. Those still live on a shared network drive every artist can reach. The database is the catalogue; the network drive is the library shelves. Both need to be shared, and they’re independent of each other.

A note on scope, because it changes everything below. This database isn’t a general-purpose company database platform. It’s a dedicated metadata backend used exclusively by Project Manager — no other applications, no external services, no web exposure by design, no user-written SQL. That narrow, single-purpose role is why the setup in this guide is deliberately simple: it’s the right amount of engineering for the job, not a shortcut.

The good news: you do not need a database expert for this. If your studio has a sysadmin, this is a perfect job for them. If it doesn’t — that’s exactly who this guide is for. Set aside an unhurried half hour and follow the steps in order.

Both are free, both are fully supported, and the setup is almost identical. Project Manager works with either.

• MariaDB (recommended for small studios). A community-driven, open-source database from the original MySQL developers. It installs cleanly and avoids an authentication change that the modern MySQL installer introduces (Section 5). For a small team, it’s the path of least resistance.
• MySQL (the industry standard). Hugely popular with extensive documentation. A solid choice — just note the authentication step in Section 5.

Which version? Don’t memorise a number — it changes between plugin releases. Project Manager tells you what it needs: open Project Manager → Preferences (gear icon) → Database tab, where the minimum supported versions are listed. Download that or newer from the official site.

This guide uses MariaDB in its examples. Where MySQL differs, it’s flagged.

---

Get this right and you avoid the most common headache.

Don’t install the database on a render node. During rendering, CPU and RAM are at 100%, the database stops responding in time, and Project Manager appears to “freeze” for everyone. (If the server ever becomes unreachable, Project Manager falls back to the local database — no data is lost — but a stalled library mid-deadline is no fun.)

Good choices:

• A dedicated file server or NAS — often ideal, since it’s already always-on (see the NAS caveat in the FAQ).
• Any reliable studio workstation that is always on while artists are working.

The only hard rule: the database computer must be available whenever anyone needs the library.

Does it need to be powerful? No. Project Manager’s database traffic is lightweight — it’s text metadata, not the asset files themselves. A modern workstation or NAS on a gigabit LAN is far more than enough, whether you have 5 artists or 50. Remote users on a VPN may see slightly slower refreshes, but day-to-day work stays comfortable.

Download MariaDB (recommended) or MySQL Community Server from its official website and run the installer. You can accept most defaults; only three screens need attention.

Custom Setup.
Keep Database instance selected.
The bundled HeidiSQL is listed here too — leave it ticked, you’ll use it in Section 4 to create the account.

---

Custom Setup — keep Database instance selected, and leave HeidiSQL ticked; you'll need it shortly.

User settings.
Set a strong password for the root account and save it somewhere safe — changing it later requires extra reconfiguration, so it’s worth getting right the first time.
Leave “Enable access from remote machines for ‘root’ user” unchecked.
This is intentional: root stays local for security, and the network-accessible account you create in Section 4 (projectmanager) is what the team will actually connect with.
Do tick “Use UTF8 as default server’s character set” to ensure asset names, tags and paths with non-Latin characters are stored correctly.

---

Set the root password. Keep "Enable access from remote machines for 'root' user" off — remote access goes to the dedicated account, not root. Do tick "Use UTF8 as default server's character set" to ensure asset names, tags and paths with non-Latin characters are stored correctly.

Database settings.
Keep Install as service ticked (the database then starts automatically with the computer — no one launches anything by hand).
Keep Enable networking on with TCP port 3306.
Leave the InnoDB engine settings at their defaults.

---

Install as service, networking on, port 3306. Leave InnoDB settings as-is — Project Manager works with the defaults

Project Manager needs a database account to connect with. For a small studio, one shared account for the whole team is the simplest and most reliable setup — every artist’s machine uses the same login. A database server handles many simultaneous connections under one account by design; that’s a normal, intended pattern, not a workaround.

Why one account is fine here: because this server is a dedicated Project Manager metadata backend (see “A note on scope” above), there’s no multi-tenant separation to enforce, no other application sharing the server, and no granular access control to design. Fewer accounts also means fewer places for a setup mistake. If your studio has stricter internal security policy, an advanced admin can of course create per-user accounts and tighten permissions manually — see the note at the end of this section.

The privilege the account needs

The Project Manager account needs full (global) privileges on the server.

This is a deliberate design choice, not over-permissioning. On first connection, Project Manager creates and maintains its own schema and tables automatically — on first launch and again during version upgrades. To do that reliably it needs administrative rights, including the CREATE TABLESPACE privilege (Project Manager stores its data using an InnoDB configuration that requires it).

Granting full privileges on a server used only for Project Manager metadata avoids partial-permission states during schema creation, updates, and maintenance — and removes a whole category of “works on one machine but not another” support issues. It’s the right trade-off for an embedded, single-purpose backend.

If the account is missing this privilege you get a confusing symptom: the connection succeeds, but tables aren’t created, so tags and changes quietly fail to save. Almost every “my changes keep disappearing” report traces to exactly this.

You do not need to create the schema yourself — Project Manager builds it on first launch. You only create the account.

🔒 Keep this account scoped to Project Manager. Since it has full server access, don’t reuse it to manage anything else (accounting software, a website, and so on). If the studio runs other databases on the same machine, create separate, restricted users for those. Powerful account → Project Manager only.

How to create the account (HeidiSQL)

You’ll want a graphical client. HeidiSQL is small, free, and the easiest option, and handles both MariaDB and MySQL well. (MySQL Workbench also works; for MariaDB, HeidiSQL is smoother.)

1. Open HeidiSQL and connect using root and the password you set during installation.
2. Go to Tools → User manager.
3. Click Add. Give the account a clear name (e.g. projectmanager) and a strong password — not admin or 12345.
4. For Host / “From”, allow it to connect from the network (% for any host, or restrict to your subnet for tighter security).
5. Under Global privileges, grant full access, ensuring CREATE TABLESPACE is included.
6. Save. That account is now ready for every artist’s machine.

(most important image in the guide)
HeidiSQL → User manager: account projectmanager,
From host set to the studio subnet (not localhost), and the Global privileges list fully ticked.
CREATE TABLESPACE is the one that matters most — without it, Project Manager connects but silently fails to create its tables

For studios with stricter security needs (optional, advanced).
The simple setup above is recommended for most small and mid-sized studios. If your policy requires least-privilege, an experienced admin can instead create the schema-creation rights only as needed, restrict the account to the Project Manager schema after first launch, and use per-user accounts.
This is more maintenance for the same result on a single-purpose server, which is why it’s optional rather than the default.

This is the most common cause of a failed Test Connection with modern MySQL — and a reason MariaDB is the smoother choice for non-technical setups.

MySQL 8.0+ defaults new accounts to an authentication method called caching_sha2_password. Project Manager’s connection may not negotiate it cleanly, producing an access-denied error even when the username and password are correct.

The fix: create the account with the classic authentication method instead of caching_sha2_password.

• In MySQL Workbench: on the account’s Login tab, set Authentication Type to Standard. (Workbench labels the classic mysql_native_password method as “Standard” — don’t go looking for the literal plugin name in the dropdown.)
• In HeidiSQL: use the small dropdown arrow at the end of the Password field in User manager to pick the authentication plugin.

MariaDB uses the classic method by default, so MariaDB users can skip this entirely.

MySQL Workbench → Users and Privileges → Login tab:
set Authentication Type to Standard.
This is the classic method Project Manager connects with reliably.
(Set “Limit to Hosts Matching” to % or your studio subnet so artists on other machines can connect — not localhost.)

The artists’ machines need to find the server and be allowed to connect.

Find the server’s IP address:

1. On the database computer, press Win + R, type cmd, press Enter.
2. Type ipconfig and press Enter.
3. Note the IPv4 Address line — that’s your server’s address (typically 192.168.1.x or 10.0.0.x).

Run ipconfig and read the IPv4 Address line — that's the server address artists will enter in Project Manager. Use the address on your real network adapter (ignore virtual adapters like VirtualBox's 192.168.56.x).

Open the firewall (single-office network):

On the server, open Windows Defender Firewall with Advanced Security, select Inbound Rules, and click New Rule to launch the wizard.

---

Step 1 — Rule Type: choose Port.

Step 2 — Protocol and Ports: select TCP, then Specific local ports and enter 3306.

Step 3 — Action: choose Allow the connection. Continue through the remaining steps (Profile, Name) with the defaults and finish

If you need remote access (working from home):

Don’t forward port 3306 directly to the internet via your router — exposed database ports are routinely scanned by automated bots, so this is a real risk.
Two safe routes:

• Easiest — a VPN. Tools like Tailscale, ZeroTier, or Radmin VPN securely link computers over the internet. The remote artist enters the server’s VPN IP address and works exactly as if in the office. For most studios this is the right answer.
• Advanced — static IP allow-list. If you must expose the port, configure the server firewall to accept connections on 3306 only from the specific static IP addresses of your remote staff, and block everything else.

Do this on each artist’s machine:

1. Open 3ds Max and launch Project Manager.
2. Go to Preferences (gear icon) → Database tab.
3. Select MySQL / MariaDB.
4. Host Name: the server’s IP address from Section 6 (e.g. 192.168.1.50, or the VPN IP). Don’t use 127.0.0.1 / localhost unless you’re configuring it on the server computer itself — this is the single most common connection mistake.
5. Port: 3306.
6. User Name & Password: the account you created in HeidiSQL.
7. Click Test Connection. A success message means you’re connected.
8. Migrating an existing local library? If you already have tags, collections, and comments locally, click Copy Database → Copy from SQLite to MySQL. When prompted, set Convert paths to: Network so paths resolve for everyone. Do this on ONE computer only — the first one. Everyone else just connects to the now-populated shared database; copying again duplicates data.

Project Manager → Preferences → Database: select MySQL, fill Hostname, Port, Username and Password, then Test connection. The success dialog confirms everything is wired up. (The panel also shows the recommended MySQL/MariaDB versions — your single source of truth for which version to install.)

Your studio now shares one library. Project Manager tracks changes and refreshes automatically, so when someone adds a folder or catalogue it normally appears for everyone on its own; if a change is slow to show, a manual refresh (right-click in empty space → refresh, or refresh the current folder) forces it.

FAQ

Utility | Plugins

Project Manager

Utility | Plugins

Batch Render&Relink

Utility | Plugins

Models Manager

Utility | Plugins

Materials Manager