EDIT: Man I apologize in advance for this wall of text lol
When I have handled this type of things in the past (before I started working with Ignition, so this is pre-Ignition me talking) typically we’d handle a lot of this with schema changes. So we would break eatch functional section of data into a different schema in the same database. Having one database with many hundreds (if not thousands) of tables is much more common than you would think, the backend for an SAP instance can have stupidly large amounts of tables (I looked at one today with 86,000 tables in one database 
).
In ignition I typically keep a separate connection per schema, with an account defaulting to that schema each. This should help with any automated collection from let’s say the tag historian, from impacting performance for any kind of queries the user might trigger (from my understanding).
In regards to tags, i wouldn’t personally find it outrageous to treat the application as a hub & spoke, with each location an independent edge gateway who is just built to sync and that’s it. Then utilizing edge eam to synchronize any UDT types, etc. I mean fundamentally the cost of the edge node is around $700-800 USD, and it will really start to improve the overall performance of the hub when you don’t have to poll 180,000 tags all from the same gateway, and instead use the GAN to bundle updates on change, and only when necessary. If you really wanna be optimal, MQTT would be a good player here, but idk how much improvement you’d see in this setup vs cost.
Then in terms of project, you know I’m typically in perspective, so this may be different if you’re base is in vision. In Perspective im typically able to make things so dynamic as to setting a session property to my current “location” that I’m interested in, and then just keeping a fundamentally similar tag structure at each edge node to allow the app to dynamically look at different sections. And I’m not just talking about a single template that works for multiple, but maybe an accordion that looks at the different types of units (mix tanks and extruders for example) and can dynamically show entirely different views/types of data based of that unit type. Therefore I will handle all of my visualization through the hub, in the smallest set of dynamic pages possible.
Fundamentally I don’t know if this is the best structure possible, and I’m sure certain @pturmel will have several ways this could be improved and simplified further, but this has been the architecture that my team and I find simplest and the most organized to manage in a scenario like what you’re describing.
In regards to your client adding more stuff to the gateway, I typically try to urge mine not to do this, but it’s their system so they could really do what they want. However we typically clarify that if they start adding their own stuff, we’re not responsible for any performance/data issues caused by their newly constructed together additions. This is also why the first step in any new gateway is to change the admin password, setup credentials with roles for project create/designer, and limit access until someone else needs it. Then down the road there’s at least a small chance that new addition gets bounced off of you before they do it while they try to figure out which roles they need, and you get the chance to help them save time/money by doing things 10x faster.
Not saying these things are all perfect solutions, but they are the best my team has come up with so far.
