Sparx EA Repository Database Options: SQL Server vs MySQL vs PostgreSQL — Which to Choose

The short version: all three databases work behind a Sparx EA repository. SQL Server is the default in Windows-heavy enterprises, with the deepest compatibility history and the most mature tooling. PostgreSQL is the strongest fit for Linux and cloud-native deployments — it scales well, carries no licensing cost, and hosts cleanly on every major cloud. MySQL is the lowest-cost route for smaller teams and simpler setups, with limits that show at larger scale. The right call comes down to your existing infrastructure, your team's skills, your cloud strategy, and your budget. Whatever you pick, Pro Cloud Server is required for multi-user access.

Why the database decision matters

The database is the foundation of your EA repository. The Sparx EA client can be reinstalled, upgraded, or replaced without consequence. The database cannot — it holds the accumulated architecture content, governance history, and model relationships your practice builds over years. A weak choice is not fatal, but it is costly to undo: moving a repository between database platforms means careful schema handling, testing, and downtime.

That makes this a decision worth making deliberately, before deployment begins.

The two enterprise-grade choices, head to head

For most teams the real decision narrows to two candidates that both scale to large, busy repositories: SQL Server and PostgreSQL. MySQL is a distinct, cost-led option covered below. Here is how the two enterprise-grade databases compare on the factors that actually drive the choice.

MySQL — the lowest-cost route

Best when: you have a smaller team, a simpler deployment, existing MySQL expertise, or a strict floor on infrastructure cost.

Compatibility. MySQL is supported, but historically it has had more edge cases than SQL Server or PostgreSQL. Basic repository operations run without issue; at larger scale or with more complex queries, occasional quirks surface.

Scale. Fine for small to mid-size repositories. For larger ones — heavy relationship traversal or high concurrent user counts — MySQL can become limiting. If you expect significant growth or many concurrent users over time, PostgreSQL or SQL Server are the safer long-term bets.

Cloud. Amazon RDS, Azure Database, and Google Cloud SQL all offer managed MySQL, though the ecosystem is slightly less mature than PostgreSQL's for enterprise workloads.

Backup. mysqldump for logical backups and the binary log for point-in-time recovery; managed services add automated backup. For small repositories this is entirely adequate.

Cost. MySQL Community Edition is open-source and free, and most Sparx EA deployments use it. MySQL Enterprise Edition adds monitoring, backup, and support at a corresponding licensing cost.

Decision table

Environment	Recommended choice	Reason
Windows enterprise with existing SQL Server infrastructure	SQL Server	Native ecosystem, DBA familiarity, mature tooling
Linux servers or cloud-first infrastructure	PostgreSQL	No licensing cost, excellent cloud hosting, strong performance
Azure hosting preferred	SQL Server (Azure SQL) or PostgreSQL (Azure Database)	Both work well; SQL Server if you already have an Azure SQL footprint
AWS hosting preferred	PostgreSQL (RDS)	Broadest managed-service support, no licensing cost
Small team, simple deployment, cost priority	MySQL	Lowest infrastructure cost for uncomplicated workloads
Large repository planned (50,000+ elements)	SQL Server or PostgreSQL	Better query performance and scale characteristics
High concurrent users (30+)	SQL Server or PostgreSQL	Stronger concurrency handling
New deployment, no existing database infrastructure	PostgreSQL	Best balance of performance, cost, and cloud flexibility

A note on Pro Cloud Server

Whichever database you choose, Pro Cloud Server is required for multi-user Sparx EA deployment. PCS sits between the Sparx EA clients and the database, handling connection management, authentication, security, HTTP/HTTPS access, and model streaming.

It is database-agnostic. PCS connects to SQL Server, PostgreSQL, and MySQL over ODBC, and the configuration process is broadly the same across all three — the database-specific part is the ODBC driver and connection string. Our Configure the Solution engagement covers PCS configuration for every one of these platforms.

Trying to share a repository across multiple users without PCS — through direct database access — is impractical in most enterprise settings. It sidesteps authentication management, rules out HTTPS access, and supports neither model streaming nor web access. For any serious multi-user deployment, PCS is not optional.

Migrating between databases

If you start on one database and later need to move — say, from MySQL to PostgreSQL as the repository grows — Sparx EA provides repository transfer utilities. Migration is possible, but it involves downtime, testing, and careful schema validation. It is not a casual operation.

Which is exactly why the initial decision matters. Choosing on current team size rather than growth trajectory is a common mistake. If you expect the practice to scale meaningfully within two to three years, pick the database that supports that scale from day one — and if you are still mapping out the wider setup, our Configure the Solution track and the broader architecture leaders path can frame the rest of the foundation around it.

Frequently asked questions