# Scale-out vs single gateway architecture **URL:** \ **Category:** Ignition\ **Tags:** vision\ **Created:** [November 25, 2024, 3:02pm UTC](https://forum.inductiveautomation.com/t/scale-out-vs-single-gateway-architecture/99074 "2024-11-25T15:02:07Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Alex\_Chellew](https://avatars.discourse-cdn.com/v4/letter/a/47e85d/32.png) [@Alex\_Chellew](https://forum.inductiveautomation.com/u/Alex_Chellew)\ **Post date:** [November 25, 2024, 3:02pm UTC](https://forum.inductiveautomation.com/t/scale-out-vs-single-gateway-architecture/99074/1 "2024-11-25T15:02:07Z")
Hello, I have a general question about when scale-out architecture is recommended vs a single-gateway. Specifically, I'm curious about why & when would separating a project into multiple gateways be recommended vs a single gateway. Our current project utilizes two back-end gateways for PLC connections and for tag providers / history and a front-end gateway for the Vision clients. I've seen it mentioned that scale-out architecture is recommended for scalability for larger projects but haven't seen much explanation as to why it is better for scalability. Couldn't a single large gateway performing all the tasks be used, or does this perform worse in practice? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [November 25, 2024, 3:06pm UTC](https://forum.inductiveautomation.com/t/scale-out-vs-single-gateway-architecture/99074/2 "2024-11-25T15:06:44Z")
> [@Alex\_Chellew](#): > > Couldn't a single large gateway performing all the tasks be used, or does this perform worse in practice? It can perform worse in practice, because workload for things like: - a lot of Vision Clients - a lot of Perspective Sessions - large or many DB queries - large or many Alarm Status queries - large or many History queries - many devices can vary quite a bit, and for things like devices especially, there is a benefit to having steady and predictable memory usage patterns, while all of the other things on the list tend to cause more "bursty" and unpredictable usage. Also, at least in theory, you can scale a Perspective front end horizontally (like thousands of client sessions? across multiple front end gateways, anyway) if you decouple it from the back end. It may also work for Vision, not sure. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 25, 2024, 3:54pm UTC](https://forum.inductiveautomation.com/t/scale-out-vs-single-gateway-architecture/99074/3 "2024-11-25T15:54:03Z")
In my experience, it is not the backend that needs scaling, but the front end. A backend on decent hardware that just interfaces with devices, pushing history to a database and, if not edge, performing regular DB transactions with devices, doesn't bog down until you hit hundreds of thousands or millions of tags. Java is really good at such workloads. User interfaces are the primary source of grief in big systems. Big history queries are the most common culprit, especially in Perspective (Vision hands off the raw data to the client). I've watched Perspective users bog down a gateway enough to disrupt history storage. In some cases, causing a gateway restart (with data loss) due to memory exhaustion. For best results, make your user interfaces query history against database replicas, not the live backend's database. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [November 25, 2024, 4:15pm UTC](https://forum.inductiveautomation.com/t/scale-out-vs-single-gateway-architecture/99074/4 "2024-11-25T16:15:58Z")
I have had similar experiences. I would say that it's good to scale out your visualization from your data gateway if you're running a large number of clients. What constitutes a large number of clients is variable depending on your infrastructure and screen designs so use the status page as your guide to how taxed your system is.