Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

DB: Unexpectedly growing "tests" table



I’m evaluating Testrail as possible replacement to currently used TCMS.
I see the strange thing in Database: Testrail populates “tests” table with all test-cases existing in suite when I create run in specific suite. Even the run consists of only one test-case.
This may not be visible if suite consist of hundreds test-cases. But if several suites consist of dozen thousand test-cases and project contains hundreds run from these suites, “test” table grows extremely fast.

Small calculation allows to estimate that each run require adding one row “runs” table (~1000 bytes) and one row for each test-case existing in the suite (~66 bytes per row). In case if test-suite in project consists of 1000 test-cases, every run is costs ~67 kB. This calculation doesn’t include space required for indexes and row allocation in DB pages.

This looks like “wasting” DB space with data which never will be used.

Dividing suites to smaller suites may help to reduce “wasting” space. But it will also increase complexity of supporting, planning and managing projects.

This issue may partially be fixed by adding Hierarchical Test Suites support to Testrail. This functionality was requested several times previously. But it is not still implemented.


Hi there!

Thanks for the feedback. We specifically designed TestRail’s database to scale well and the tests table simply holds pointers to the actual test cases to store results. We have many large teams using TestRail (1,000+ testers) for years without issues. We generally don’t recommend using separate test suites anymore and this wouldn’t be necessary.

I hope this helps!



Hey Dennis

we are having the same hesitations with this implementation, our database had grown 8gb in less then a month due to the issue mentioned above and it ran out of disc space. we solved it by adding disc space so our team could continue working, but this does not seem to be a sustainable way of doing this. As a team we are moving to faster releases of our product and that means more and more runs and therefore more and more wasted space.

could we just run a script on the database to drop all those irrelevant test cases? it would of course be better if this did not happen in the first place.

would appreciate it if a solution could be suggested aside from putting in more and more diskspace.


Hi John,

Thanks for your reply! If your database is growing that quickly than it is likely that you close many test runs regularly via e.g. automation. If this is the case, we would recommend keeping automation runs active for a longer period of time to re-use them for your automation so that the database doesn’t continue to grow with many closed test runs. You can also use the TestRail API to delete old automated test runs when you no longer need them, as this will help to keep the database size down.

Please note that you should never directly write to or change anything in TestRail’s database. This would break the consistency of the database, even small changes you might find unproblematic, and your TestRail instance would be immediately unsupported. You wouldn’t be able to upgrade anymore and we wouldn’t be able to support the instance anymore.

We specifically designed the API so you can change/update data in a safe way as an alternative instead. So please never directly write to the database, as you would end up with an unsupported database and you would need to restore a full database backup at some point and lose all data your team added in the meantime. In general, with normal usage of TestRail the database wouldn’t grow so rapidly.

Hope this helps!