EngineeringMechanical EngineeringData
SOLIDWORKS PDM Architecture & Server Topology
Most administrators describe a vault as the server where the files live. That description is wrong in a specific way, and the error is what makes backups fail — file content and metadata live in different places, managed by different services, captured by different mechanisms.
- Group · Data
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 19 min
01 Why the Architecture Matters
Most administrators can describe a vault as "the server where the files live". That description is wrong in a specific way, and the error is what makes backups fail.
File content and metadata live in different places, managed by different services, backed up by different mechanisms. A vault is not one system; it is three cooperating server roles plus a client cache, and a restore is only clean when the pieces were captured consistently with one another.
Understanding the split also explains performance behaviour that is otherwise mysterious. A slow check-in and a slow search have different causes and different remedies, because one is dominated by storage throughput and the other by database performance.
Supported database and operating system versions, component prerequisites and their end-of-support milestones change with every release and are published per release. Verify against current release notes and system requirements before specifying, installing or upgrading a server.
02 The Three Server Roles
File content sits on the archive server as ordinary files. Metadata sits in the database. Neither is complete without the other, and neither knows the other has been backed up.
A restore is clean only when both were captured at the same point in time. Restore an archive set alongside a database taken hours later and you get metadata referring to files that were never captured, plus files with no metadata — a state that is recoverable only with manual reconciliation.
03 Where Data Physically Lives
Archive folders
File content is distributed across a fixed set of hexadecimal-named folders beneath an archive root — a simple hashing scheme that prevents any single directory accumulating an unmanageable number of files. From the operating system's point of view these are ordinary folders containing ordinary files, which is why they can be captured by any conventional backup tool.
The root location is set at installation and can be changed, so it should never be assumed. Confirm the actual configured path on the server rather than relying on the default when planning backup or capacity.
Databases
Each vault has its own database. Alongside them sits a single master database shared across every vault on the instance, holding the registry of vaults themselves. A backup that captures the vault databases and omits the master is incomplete, and this is a common oversight because the master is easy to overlook when there is only one vault.
Archive server configuration
The archive server's own settings — login types, archive paths, vault registration — are exported as a discrete settings artefact through the archive server configuration tool. This is the third backup component and the one most often missed, because it is neither files nor database and does not appear in either backup routine automatically.
Exporting the archive server configuration captures the settings only. It does not capture a single file of archive content. Administrators who have taken a settings export and believe the archive server is backed up discover the gap during a restore, which is the worst possible moment.
04 The Local Vault View
The client-side working copy. Understanding what it is — and is not — resolves most user confusion and one significant data risk.
A local vault view presents the vault as a folder on the workstation. Files appear there whether or not they have been retrieved; opening one retrieves it from the archive server into the local cache. A checked-out file is being edited locally and its changes exist only on that workstation until it is checked in.
What it is
- A cache. Content can be cleared and re-retrieved without loss.
- The place a checked-out file is edited before it returns to management.
- Local storage, which is why it must not be captured by folder redirection policy.
- Per-user, and its root path should be consistent across the fleet.
What it is not
- Storage. Nothing should exist only here.
- Backed up. No server-side backup protects a checked-out file.
- Shared. Two engineers' views are independent caches.
- Automatically current. Content can be stale until refreshed.
A workstation failure loses everything checked out on it. That exposure is bounded only by how long files stay checked out, which is a process question rather than a technical one.
Establish an expectation that work in progress returns to the vault at defined points — end of day, before leaving a design for another task, after any substantial change — rather than only at completion. Long-running check-outs also block colleagues, so the discipline serves two purposes.
05 Topology Options
| Topology | Arrangement | Suits | Constraint |
|---|---|---|---|
| Single server | Database engine and all vault server components on one dedicated machine | Small environments, roughly fifteen users or fewer | Database and archive compete for the same processor, memory and storage |
| Split | One server for the database engine, another for the archive server | Medium and large environments; the recommended arrangement | Two servers to specify, patch and back up consistently |
| Split with web access | Split, plus a web server for browser-based access | Where non-CAD roles, suppliers or field staff need released data | Available at the upper capability tier only; adds a security surface |
| Replicated multi-site | Central database server, with an archive server replica at each site | Multiple engineering locations over WAN links | Upper tier only. Archives replicate; the database stays central |
Sizing and storage
The two components have opposite resource profiles, which is why separating them helps. The database engine is processor- and memory-intensive with a demanding but modest-volume storage pattern. The archive is storage-volume and throughput-intensive with modest processor demand. On one machine they compete; separated, each can be provisioned appropriately.
- Operating system and database on redundant solid-state storage. Mirrored, for both performance and resilience.
- Archives on dedicated high-throughput volumes. Separate from the operating system, with substantial capacity headroom — every version of every file is retained indefinitely.
- Provision the database generously. It is the component that determines how the system feels to users, and it responds well to memory.
- Install nothing else on either server. Co-tenanting other applications with the database engine in particular is a reliable source of intermittent performance complaints.
- Plan archive growth deliberately. Retention is unbounded by design; capacity planning must assume continual growth rather than a steady state.
It installs, it appears to work, and it is a poor decision. Desktop editions are licensed for single-user desktop use rather than multi-user server workloads, and they lack the management, scalability and resilience capabilities of server editions. Desktop-class hardware also lacks the redundancy appropriate to a system holding the organisation's entire design record.
06 Database Edition & Its Consequences
The capability tier determines which database edition is used, and that choice propagates into limits that are not obvious from the product comparison.
| Aspect | Free edition (lower tier) | Full edition (upper tier) |
|---|---|---|
| Database size | Hard ceiling per database | Effectively unconstrained |
| Processor and memory use | Restricted | Uses available resources |
| Scheduled maintenance | No native scheduling | Native maintenance plans |
| Automated backup | Must be scripted | Scheduled through maintenance plans |
| Licence cost | None | Separately licensed |
The size ceiling is reached without warning. Metadata volume grows with file count and history depth, not with file size. A vault approaching the limit gives no obvious signal until operations begin failing. Monitor database size as a routine measure and know the headroom.
The absence of native scheduling makes backup a manual design problem. On the free edition, database backups must be scripted deliberately. Environments that rely on someone remembering will have a gap on the day it matters, and that gap is discovered during a restore.
07 Prerequisites & Dependencies
The vault depends on several platform components with their own version constraints and their own retirement schedules. These are the most common cause of an upgrade turning into an infrastructure project.
- Database engine version. Supported versions are declared per release and retired on a published schedule, usually announced a release or two in advance. A database upgrade may be a prerequisite for the next vault upgrade.
- Server operating system version. Same pattern, same consequence.
- Database connectivity driver. A specific driver family and version range is required on both servers and clients. Newer major driver versions are not automatically supported, so a general driver update pushed by IT can break connectivity.
- Embedded browser component. Required on archive servers and clients for parts of the interface. Absent, elements of the client fail in ways that do not obviously point at a missing component.
- Licence manager version. Must be at or above the vault version, which is why it is upgraded first.
- Client and server version match. The vault client year-version must equal the server year-version — there is no partial upgrade.
- CAD integration span. A current-year vault typically integrates with the current and two preceding CAD releases, which allows CAD upgrades to be staged even though the vault client cannot be.
Record every platform component the vault depends on, its installed version, its supported range for your release, and its published retirement milestone. Review it annually before upgrade planning begins.
This one document converts the most common upgrade surprise — discovering a database or operating system retirement mid-planning — into a scheduled piece of work with lead time. It takes an hour to build and saves a quarter.
08 Multi-Site Replication
Available at the upper capability tier. It solves file retrieval latency across sites, and does not solve database latency — a distinction that determines whether it will meet expectations.
In a replicated arrangement, each site hosts its own archive server holding a replica of the file archives, while a single central database server continues to hold all metadata. Clients retrieve file content from their local replica at local network speed, but every metadata operation — browsing, searching, checking out, transitioning state — still reaches the central database over the WAN.
What replication fixes
- Retrieval of large assemblies at a remote site, which is otherwise the dominant cost.
- Check-in throughput, since file content is written locally and replicated in the background.
- Resilience of file content, which now exists in more than one location by construction.
What it does not fix
- Metadata latency. Browsing and searching remain WAN operations.
- Database availability. A central database outage stops every site.
- Backup complexity. Each replica needs its own archive and settings backup.
- Administrative overhead. More servers, more prerequisites, more upgrade coordination.
Remote users frequently expect replication to make the vault feel local in every respect. It will not — folder browsing and search will remain noticeably slower than at the central site, because those are database operations.
Where metadata latency is the actual complaint rather than file retrieval time, replication is the wrong remedy and will disappoint after significant expenditure. Measure which operations are slow before committing.
09 Architecture Checklist
- Roles understood and documented. Which machine hosts which role, with actual configured paths recorded rather than assumed defaults.
- Archive and database separated. Beyond roughly fifteen users, on distinct machines with appropriate storage for each.
- Server-class operating system. No vault server component running on a desktop edition.
- Dedicated servers. No unrelated applications co-tenanted, particularly alongside the database engine.
- Storage provisioned by role. Redundant solid-state for operating system and database; dedicated high-throughput volumes with headroom for archives.
- Archive growth planned. Capacity forecasting assumes continual growth, since retention is unbounded.
- Database size monitored. Particularly on the free edition, where a hard ceiling exists and gives no warning.
- Master database included in backup. Not only the individual vault databases.
- Archive settings exported. Recognised as a third backup artefact, distinct from archives and database.
- Vault views local. Client cache roots resolve to local storage and are not captured by folder redirection.
- Check-in discipline established. Work in progress returns to the vault at defined points, not only at completion.
- Prerequisite register maintained. Every dependency, its version, supported range and retirement milestone, reviewed annually.
- Driver updates controlled. Database connectivity driver excluded from general update policy on servers and clients.
10 Frequently Asked Questions
Can we run the vault servers as virtual machines?
Yes, and it is common. Server components virtualise well provided two conditions hold: processor and memory are reserved rather than shared on a best-effort basis, and storage delivers genuine throughput.
The failure pattern is a vault placed on general-purpose shared storage alongside unrelated workloads. Check-in and check-out performance degrades and the cause is very difficult to identify from inside the application, because every component reports itself as healthy. Confirm the platform appears on the current validated list, and specify storage deliberately rather than accepting whatever the virtualisation estate provides by default.
Our vault feels slow. Where do we start?
Separate the symptom first, because the two halves of the architecture have different remedies. Slow retrieval, check-in and check-out of large assemblies point at archive storage throughput or network path. Slow browsing, searching and state transitions point at the database engine or the client-to-database network path.
Then check the three cheap causes before anything else: antivirus scanning the archive folders or the local vault view, the database engine sharing hardware with something else, and archives on storage that is slower than assumed. These account for a large share of performance complaints and none requires additional expenditure.
How much storage should we plan for the archives?
Start from your current native data volume, then account for two multipliers. Every version of every file is retained, so volume grows with revision activity rather than with the size of the current design set. And check-in frequency directly drives that growth — a team that checks in after every small change will accumulate archive volume far faster than one that checks in at meaningful milestones.
Plan for continual growth with no steady state, monitor actual growth rate over the first year, and forecast from measurement rather than from the initial estimate. Provisioning generously at the outset is considerably cheaper than migrating archives to larger storage later.
Can two vaults share one database server?
Yes. Each vault gets its own database, and a single master database on the instance registers them all. This is a normal arrangement where an organisation separates, for example, current product data from an archived legacy set.
Two implications follow for backup. The master database must be captured alongside the individual vault databases, and the archive folders for each vault must be captured too — they are separate archive roots. A backup routine written for one vault and never revisited after a second was added is a common and serious gap.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.