Sparx EA Repository Database Options: Choosing Between SQL Server, MySQL and PostgreSQL

All three databases work behind a Sparx EA repository, and Sparx EA supports others as well, so check Sparx Systems’ current documentation for the full list and versions. SQL Server is the default in Windows-heavy enterprises, with the deepest compatibility history and the most mature tooling. PostgreSQL is a strong fit for Linux and cloud-native deployments, with no licensing cost and clean hosting 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.

For an architect, the database is a decision about where the architecture lives and who will keep it running. Whoever administers the database also decides how easily the model can be backed up, restored and read by other tools, including the reporting and AI tools that sit on top of it. By hand, that decision is made once during setup and revisited during an outage. AI-augmented, the repository becomes something people and AI work through every day, so the choice affects how readily tools can read it. The architect decides what the repository must support, and the database administrators decide how it is run. The model it works on is only as good as the repository underneath.

Why the database decision matters

The database is the foundation of your EA repository. The Sparx EA client can be reinstalled or upgraded without losing content. The database 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 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 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. Check Sparx Systems' documentation for the supported versions and any known limitations before you commit, especially if you expect a large repository or complex queries.

Scale. Suited to small and mid-size repositories. With heavy relationship traversal or many concurrent users, MySQL can become limiting. If you expect significant growth or many concurrent users over time, PostgreSQL or SQL Server are the safer long-term choices.

Cloud. Amazon RDS, Azure Database, and Google Cloud SQL all offer managed MySQL.

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. MySQL Enterprise Edition adds monitoring, backup, and support at a corresponding licensing cost.

Decision table

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	SQL Server or PostgreSQL	Better query performance and scale characteristics
Many concurrent users	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

A team can share a Sparx EA repository by connecting EA clients directly to the database server on a trusted network. Pro Cloud Server (PCS) sits between the clients and the database and adds HTTP/HTTPS connections without exposing the database, web access through WebEA and Prolaborate, integrations, and floating license management. Teams whose members work over the internet or from different networks, or who want web access for stakeholders, typically add it.

PCS is database-agnostic. It 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.

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.

That is why the initial decision matters. Choosing on current team size instead of growth trajectory is a common mistake. If you expect the practice to scale meaningfully, pick the database that supports that scale from day one.

If you host the repository yourself, we can build reporting views in the same database so you read from them live, and your reporting and AI tools can work from those views. Tell us which database you are considering, because the reporting layer depends on it. If the database is hosted elsewhere, we can help you set up a reporting database in something like Snowflake or Microsoft Fabric that refreshes from your EA model on the schedule you define. See reporting and Power BI.

Frequently asked questions