Pro Cloud Server keeps one authoritative repository running centrally and gives every EA client a thin, HTTP-based window onto it. CelinQ keeps a complete, fully functional repository on each architect's own machine and reconciles changes through a background sync and merge engine. Neither is a workaround for the other — the full narrative comparison, including a worked three-office scenario, is here. This page is the short, structured version.
Dimension by dimension
| Collaboration architecture | Pro Cloud Server: centralised — one authoritative repository, every client a thin window onto it. CelinQ: local-first — each architect holds a complete local repository; a background service reconciles it with a shared server. |
|---|---|
| Storage topology | PCS: single DBMS (SQL Server, Oracle, PostgreSQL) behind an HTTP service. CelinQ: a canonical copy on the CelinQ Server (SQLite or PostgreSQL) plus a genuine, fully functional local repository per architect. |
| Network dependency during modelling | PCS: a network round trip on every meaningful repository operation. CelinQ: none — reads and writes during modelling are local disk access. |
| Offline operation | PCS: requires connectivity to function; disconnection stops or degrades the session. CelinQ: works exactly as normal offline; changes synchronise when a connection returns. |
| Consistency model | PCS: strong, immediate — there is only one copy. CelinQ: eventual — local copies converge within the sync cadence (typically seconds), or on reconnection after offline work. |
| Conflict handling | PCS: prevention, via package/element-level locking. CelinQ: reconciliation, via CelinQ Fusion's deterministic three-way merge at model-fact granularity. |
| Revision history | PCS: repository-level history per Sparx's own tooling. CelinQ: an ordered revision history per workspace, with tombstones so deletions are never silently reversed. |
| Administration | PCS: central service monitoring, familiar DBMS operational patterns. CelinQ: a Control Plane covering workspaces, clients, sync throughput, open Fusion decisions, audit log and backups. |
| Authentication | PCS: Sparx's own authentication options. CelinQ: personal access tokens (PBKDF2-SHA256) and Microsoft Entra ID SSO, active side by side. |
| Deployment | PCS: a central service backed by a mainstream DBMS, following patterns most infrastructure teams already know. CelinQ: one additional service (SQLite for small teams, PostgreSQL for larger ones) on your own infrastructure. |
| Tool interoperability | PCS: Enterprise Architect and its own Cloud Services (including OSLC for cross-tool linking). CelinQ: the same server and Fusion engine also serve Archi natively — one workspace for both tools. |
| Documentation | PCS: whatever your existing EA documentation tooling produces. CelinQ: a built-in generator produces a searchable static documentation portal from the workspace, on demand or on a schedule. |
| AI capabilities | PCS: none built in. CelinQ: optional, policy-gated in-EA design generation and analysis via a provider-independent interface — off by default. |
| Best fit | PCS: teams working from well-connected locations who want a single central service and live cross-tool query access to the model. CelinQ: geographically distributed teams, real offline needs, large teams where lock contention has become a daily cost, or organisations wanting an independent semantic revision history and merge layer. |
When Pro Cloud Server may be the better choice. If your whole team sits within a short, reliable hop of the data centre, if live cross-tool integration querying the model in real time is a first-class requirement, or if your organisation is already deeply invested in Pro Cloud Server's query surface, the migration cost of moving to a different architecture has to be weighed honestly against a problem you may not actually have. Pro Cloud Server's central-repository model is the simplest architecture that satisfies a genuine real-time, single-source-of-truth requirement — do not adopt local-first replication to solve a problem your team does not have.
Go deeper
Pro Cloud Server vs Local-First EA
The narrative version, including a worked three-office scenario and the honest limits of each approach.
Why Local-First Is Faster in Practice
What "no network round trip during modelling" actually means for a working session.