Hi,

i do not think there is a limitation as such. It always depends on your organizational architecture, if you distribute TMs across multiple containers you would have better maintainability of the SQL side. The size of DB containers depends only on the amount of TUs, and not TMs.

i.e. if you have 20 milions TU's we are talking about 150GB DB file (75 GB backup) , so you should consider it...

I am not aware about any performance problems even i am talking about te size above. But maybe someone else here has different opinion?

regards,
Fana

Hi,

i do not think there is a limitation as such. It always depends on your organizational architecture, if you distribute TMs across multiple containers you would have better maintainability of the SQL side. The size of DB containers depends only on the amount of TUs, and not TMs.

i.e. if you have 20 milions TU's we are talking about 150GB DB file (75 GB backup) , so you should consider it...

I am not aware about any performance problems even i am talking about te size above. But maybe someone else here has different opinion?

regards,
Fana

Thanks a lot for this insight and for taking the time to share it Fana!

Gwen

Hi Fana and Gwen,

Well said, Fana. Another thing to consider if you are using the free Express version of SQL Server (not recommended by SDL) is that your databases will be limited to 10GB. Once it hits this limit you will not be able to add TUs to any of the TMs in that particular container.

Kind regards,
Nick

Hi,

I would also add considerations regarding SQL backup (retention) considerations:

- if you have project / working TMs which are updated on a daily basis, you might place them in a separate container (= SQL database) which is backed up daily

- if you have read-only / legacy / reference TMs, you might add them to a separate container for which no backups are taken as you would have the original TMX files

etc.

When you come into worst-case scenario and need to restore a server-based TM, you usually need to restore the whole container / DB (ideally to a separate GS server instance) and then export the affected TM, see https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0024918.

So it might be wise to spread your TMs to several containers instead of one.

Kind regards

Christine

Thanks a lot Christine for this very clear explanation. We're new to GS and have to figure out the best options taking into consideration the fact that our IT department serves thousands of people, so we need to make sure we don't bother them every other day and we have easy db restoration procedures.