I have two Retool spaces — one with around 7,000 users and another with just 10. The second one runs significantly faster, even though the apps are nearly identical in both spaces (same number of components, queries, and both connected to the same database).
While debugging the performance issue, I noticed that the Retool's native api/user query (which runs on every page) behaves very differently between the two spaces.
In the "slow" space (7,000 users), this query consistently takes around 5 seconds.
In the "fast" space (10 users), it completes in just 0.3–0.5 seconds.
Here are two screenshots showing the difference:
Could the performance issues be related to the api/user query and the total number of users in the space?
Yes, the number of users in your Retool space can directly impact the performance of user-related queries if they are fetching from users on every page load.
Here are a few ideas:
Have a look at the query breakdown by hovering over the query. This should give you hints to where you need to optimize.
Let me just clarify that I mean not query to my database but the Retool's native /api/user query
We use Retool Cloud, so we don’t have access to manage database indexes directly. But the main point is that we don’t use {{ current_user }} or any other Retool-hosted user data in our apps — yet the /api/user endpoint still takes 5–6 seconds to load on every app load.
Is there a way to disable /api/user query completely? Or reduce its size.
Got it.
I think that is a question for the Retool team. @Darren, @Tess, @Jack_T any thoughts?
Hopefully they can shed some light. Otherwise, in office hours they can help troubleshoot live.
Interesting find, I know our performance team would love to dig into this. Thank you Oleksandr for sharing those screenshots! Very helpful.
Let me get back to you on what can be done in regards to the /api/user query. My gut feeling is that this fix might take some time but I can see if the perf team has any workarounds as well
We have an engineering investigating this. The engineering manager told me that it would not be possible to turn this off. But that they did see some occasional spikes in load times of the endpoint.
With your query run time being a major outlier but seen not the only one. Hopefully the issue is an N+1 condition in the search algorithm that finds the current users data which the endpoint returns and it can be patched quickly.
For added context, even if you aren't using{{current_user}} in the app, the org needs to grab the user's data to understand what permission groups they belong to for the app to work
I think you could still connect to the cloud hosted postgresql db with PGAdmin and update the indexes with a query using that (or whatever your preferred postgresql/sql 3rd party client is.... but, PGAdmin is free ) .
Hi @bobthebear
thank you for your advice! Just have to say that we speak about Retool's native api/user query. And we are on cloud not self hosted tier.
I was just talking to our engineer on our runtime team and they were looking at response times for that endpoint and although it seems to be uncommon for the request time to spike as you are seeing.
They wanted me to double check this issue is still happening for you and on the frequency, is it every single page load that it takes around 5 seconds for that api/user query to finish?
If so I can have them dig into your org and see if they can find more clues into how to fix this.
Hi @Jack_T ,
I've checked api/user speed in our "slow" space today in the morning. And it got much more faster — around 0.3-1.0sec for all pages. Did your engineers do some magic?
At the same time, I can see at least one more slow query – themeImages.
While it takes only 100–200ms in the "fast" space, it consistently takes 3–4 seconds in the "slow" one.
I know they were working on this and monitoring the endpoint for outliers in the response time, I will have to check with them on what they found/fixed
Hi @Jack_T,
We observe that api/users's performance got much-much better in our native retool apps. But it is still slow when using Retool embed (3-5 seconds). Could you check that point as well please
) .
