Book a Demo

Author Topic: Performance impact of reverse-engineering large databases  (Read 735 times)

andrea.barroso

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Performance impact of reverse-engineering large databases
« on: August 06, 2026, 11:54:25 pm »
Hi everyone,

We are starting to import database schemas into Enterprise Architect using the Database Builder and its reverse-engineering functionality.

So far, we have only worked with relatively small databases, and we have not noticed any significant impact on repository performance. However, we are planning to import much larger schemas, including databases with approximately 5,000 tables and one with nearly 9,000 tables.

Has anyone worked with database models of this size in EA?

We would like to understand:

  • How much impact could these imports have on repository performance?
  • Is it advisable to keep several large database models in the same repository?
  • Are there any recommended practices for organizing or separating these models?
  • Are there any repository, database server, or EA configuration settings that could help maintain good performance?
  • Would using separate repositories be a better approach for schemas of this size?

Any experiences, recommendations, or potential limitations we should consider would be greatly appreciated.

Thanks in advance.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13527
  • Karma: +575/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Performance impact of reverse-engineering large databases
« Reply #1 on: August 10, 2026, 04:48:31 pm »
Hi Andrea,

The reverse engineering process itself, importing thousands of tables might take a (very) long time.
Once imported I don't believe it will have an impact on the performance of your repository.
I don't see a benefit to splitting that up into different repositories.

But you might want to think about the whole reverse engineering/comparing those very large databases.
We eventually settled on importing only a the subset of tables that we were actually using (of a large ERP system). That is about 600 tables instead of 8000. That was much faster to import/compare

Geert