Repository Options
Sparx Enterprise Architect Repository Options
Enterprise Architect (EA) stores models in a repository. The main choices are:
Repository types
| Repository option | Advantages | Disadvantages | Best fit |
|---|---|---|---|
| .eap / .eapx file (Legacy) | Simple, portable, easy to back up; useful for prototypes and individual work | Access-based; limited scalability and concurrency; weaker performance and reliability for large or heavily shared models; file-locking and network-share risks. Legacy file formats that have been replaced by .qea/.qeax files in EA 16.x and later. | Personal models, prototypes, training, small teams |
| .qea / .qeax file (aka SQLite database) | Single-file repository; fast and portable; generally more robust than legacy Access repositories. Now the default file format as of EA 16.x and later. | Still file-based; simultaneous editing and network deployment require care; less suitable for large enterprise teams | Individual users and small teams needing portability |
| Firebird database | Server-capable, efficient, relatively easy to administer; supports concurrent access and larger models | Requires database-server administration; fewer enterprise-standard operational tools and skills than SQL Server or Oracle | Small-to-medium teams and departmental repositories |
| MySQL / MariaDB | Widely available, scalable, familiar administration and monitoring; supports concurrent multi-user work | Requires DBA effort; configuration, drivers, permissions, backups, and upgrades must be managed; compatibility/version details matter | Teams standardized on MySQL/MariaDB |
| Microsoft SQL Server / Azure SQL | Strong concurrency, security, backup, monitoring, high availability, and enterprise integration; good Windows/.NET fit | Licensing and administration overhead; requires database expertise; more infrastructure than a file repository | Medium-to-large organizations and governed environments |
| Oracle Database | Enterprise scalability, security, resilience, auditing, and high-availability capabilities | Highest complexity and administration overhead; licensing and DBA costs can be substantial | Organizations with an established Oracle platform |
| PostgreSQL | Open-source enterprise database; strong reliability, extensibility, security, and scalability | Requires DBA support and careful EA compatibility/configuration; may involve more deployment work than SQL Server in Windows-centric environments | Organizations with PostgreSQL standards |
| Cloud-hosted database | Central access across locations; managed backups, availability, and scaling may be available | Network latency and outages affect usability; security and licensing require assessment; hosting a database does not automatically provide browser collaboration | Geographically distributed teams |
| Cloud/shared EA services | Reduced infrastructure burden; may provide web access, controlled sharing, and centralized management | Subscription/service dependency; feature and integration limits; data residency, access control, and export strategy require review | Teams wanting managed collaboration and publishing |
Practical recommendation
- Solo user: SQLite or a local
.eapxrepository. - Small team: Firebird, SQLite with disciplined usage, or a supported MySQL/MariaDB instance.
- Enterprise team: SQL Server, Azure SQL, Oracle, or PostgreSQL—preferably the platform already operated by the organization.
- Distributed teams: A centrally hosted, properly secured server repository or managed EA cloud service. Avoid putting a file repository on OneDrive, Dropbox, SharePoint, or a general network share for simultaneous editing unless explicitly supported by Sparx Systems.