Site collection & content database considerations, any suggestions for best practices?

Question

We're in the migration planning stages of moving from MOSS 2007 to SharePoint Server 2016 and one thing we want to avoid is having to worry about managing content databases too early.

On MOSS 2007, across our site collections, we currently are using about 300GB, split amongst however many content databases(not sure how many there are, I forgot to check). To ease the burden of our IT team, they requested that we take consider content DB sizing into consideration.

I know that a lot of the content currently in the MOSS is really old, probably going back to about 2011 or 2012-ish, and can be gotten rid of. Some of it actually does have to say. I expect we'll be able to trim 50 to 100 GB. Mind you again this 300GB is split across a handful of site collections anyway. The 3 biggest offenders had storage usage allocations of about 48GB, 50GB, and 100GB.

In our Server 2016 implementation we were going to have 9 host name site collections, 7 representing the top level departments and 2 to represent segments that are dedicated enough to warrant having their own site collection.

The thing is a lot of these departments have many program areas/divisons under them, so, in the example of that 100GB site collection, the usage is a total of the top level SC and all the subsites under it; it may have like 4 to 6 subsites. We wanted to avoid the scenario of having one area, subsite, or even the top level SC grow too large to the point where it becomes a detriment to itself and even subsites in terms of manageability.

So that leads to the thoughts I had. Regarding the 200GB amount which is more of a soft limit for back up and restoration capabilities rather than a hard limit: is this even something most people have to deal with? Is it uncommon for site collections to even come close to this amount? I'm trying to determine if content is something that an administrator should be actively and constantly managing to ensure that relevant, current content is being rotated into site collections and that stagnant content isn't just sitting in site collections, building up the size of content databases and causing administrative garbage collection nightmares later on.

My second thought was using host name managed paths to do something like this:

finance.contoso.com (site collection, Finance_ContentDB)
   Managed Path - wildcard, /divisions
          finance.contoso.com/divisions/sales (site collection, Finance_Sales_ContentDB)
          finance.contoso.com/divisions/purchasing (site collection, Finance_Purchasing_ContentDB)
          finance.contoso.com/divisions/contracts (site collection, Finance_Contracts_ContentDB)

I was thinking this would really break things up, from a management/administrative perspective, and would lend some kind of resiliency to itself. If a content DB within a hostname has an issue it won't completely take down all of the other sites related to that area of operations in the organization. Additionally, if purchasing or sales start to get too big already I can avoid the early issue of having to break it off into its own site collection because its affecting the ability of the other sites in the hostname to add/storage content. I see a few caveats though:

• Security / SharePoint group management requires more up front setup for all the site collections and needs to remain consistent, it's really more on me than anyone else
• Content Type inheritance, not really a huge deal as a Content Type Hub can be implemented
• Search, seems to be okay as I can get results from site collections under the top-level host name if I have permission
• Could be a potential annoyance with inheriting things down like CSS, page layouts, master pages, in this case I might just be duplicating a lot of work which is on me more than anyone else
• Web Parts like Excel Services can only see spreadsheets/files within the same site collection. This could be worked around with a publishing catalog but I don't think a publishing catalog full of Excel sheets for the purpose of getting them out to a basic web part like Excel Services is the answer here.

Thoughts / comments? Am I over thinking it or over-estimating how quickly content databases can fill? Should the management of content databases be a regular administrative task?