Currently, the "We Host" plans all spin up in Azure us-west-2. However, it could be possible that database resources are in other regions (say us-east or even in Europe).
Some of our customers have all of their data hosted in Europe and the turn around time has made the UI very slow.
It would be great to select a region where we would like our "We Host" plan to run.
Thanks for this request, @erichosick! Hopefully this is something we can support soon! 
Our engineering team works hard to ensure the best performance possible for our queries. We have some general performance suggestions outlined here, but the main option to consider for the time being is self-hosting your Retool instance so that you can host your Retool infra close to your managed databases.
+1
This currently is a major issue for one of our ReTool Enterprise customers as well.
For ReTool organizations on different continents, it on the one hand results in longer load times for the ReTool UI / application itself. On the other, it significantly slows down queries coming from a European client and going against a European database. These need a minimum of two additional round trips across the pond, adding at least 300ms to each request.
When multiple queries build on top of each other for user-interactive functionality, this can cause noticeable delays that hinder user productivity inside the app.
While self-hosting is great for organizations, that want to squeeze out the last millisecond of performance, this comes with a great amount of additional IT maintainance effort.
It would be great if the existing "outbound regions" (us-west-2, eu-central-1 and ap-southeast-1) would also be supported for ReTool hosting.
Offering this as a (one-time) organization- or space-wide setting would already be a big improvement for customers in European or Asia.
As an additional Enterprise feature, multi-region deployments could be interesting for organizations in which the same set of ReTool apps is used by employees on multiple continents (keeping data residency in one of the regions, while hosting replicas of the latest deployed version of the application in the other two).
ReTool Agency Office Hours 2025-04-30 – Technical Support Question:
How much does the latency of ReTool hosting everything in us-west-2 affect other agencies and their customers in Europe? Are there any additional measures or workarounds that can be taken to improve performance without having to resort to self-hosting?
Hi @Tim_Bodeit_DPM,
Thanks for prompting the discussion and adding a +1. I am looking forward to hearing from other builders on whether they have experience with this issue.
As far as this feature request, I don't have an update to share yet. We still recommend exploring self hosting options when possible, as well as general performance best practices. We also added query performance best practice doc.
For context, the outbound regions were added to reduce latency caused by the physical distance between customers/their resources and our servers. When you set the outbound region, 4 long round trips are replaced by 1 long round trip + 4 very short ones. When we launched this feature, customers saw performance gains in the high 100s of milliseconds upon setting their outbound region.
For folks with the outbound region set that are still experiencing very slow page loads, requests, or queries, it could be worth also looking into issues with the network, resources, etc. For queries, the query performance tooltip can be a helpful resource
Definitely don't want to put folks on the spot, but curious if you happen to have any additional thoughts? cc @stefancvrkotic @MiguelOrtiz @dcartlidge
I've always started with the assumption that any reasonably complex Retool app will not perform as well as a native/self-hosted app. The payoff is the speed and simplicity of development, flexibility, maintenance etc etc
Several unavoidable layers will add latency, so optimising queries, their timing, and the volume of data returned is crucial to delivering something that is suitably performant.
I usually start with questioning "does the user want to see a page of 10k records and search for the one they want or do they know what they want to search for or do they just want me to show them what they most likely need to see" etc. Quite often this is an issue where the requirement is to replicate what an existing system does now (rather than improve on it).
This is all quite subjective, of course, and the context of what "acceptable" performance means will vary by org/app/use case.
Having a cloud hosted Retool in the EU region, closer to my data source, would undoubtedly be a benefit and avoid the complexity and cost of self-hosting.
As an example, here's the mini app I used to test performance of the outbound region switch.
This is a deliberately complex/big query that runs against my AWS DB in EU-West
Left panel is using the outbound region as EU
Right panel is using the default outbound region in US
I would imagine an EU hosted Retool cloud instance would further reduce the latency considerably.
So, in answer to the question, I'm not an agency, but as an EU Retool cloud org, the hosting location and latency affect us, and the workaround is constant optimisation and designing around it.
Thanks so much for taking the time to share this detailed insight! 
One tip my teammate in the UK shared is being mindful of how many quick actions the app has. A single action may have negligible latency, but if there are a lot of quick actions in an app, it could compound the overall feeling of latency. To that point, I agree, it could be helpful to anticipate how an end user will use the app (do they really need to see all records or can you preemptively filter the data)
Would like to differentiate latency and throughput here.
Filtering data will help wherever throughput or compute complexity is causing a bottleneck.
Latency on the other hand I would understand as the "time to first byte" affecting even the smallest payloads.
For this, performance implications scale over number of requests made, rather than the size of each request.
+1
