Queries run in Retool take longer per join then on the SQL server it is connecting to

  1. My goal: Quickly load up information from our AWS database from Retool with times that are closer to how long it takes from mySQL workbench
  2. Issue: Some of our larger queries with joins have extended load times even before touching the transformer which are notably longer than the time it takes for that same query to be run on our SQL server from Workbench.
  3. Steps I've taken to troubleshoot: The same MySQL query broken down into 2 seperate Retool queries and then combined using a transformer had a much quicker load time then the full query. To be more concrete, on a 40 column query (1 of the inner joined tables is pulling 24 columns and the other is pulling 16 columns), it took 33 seconds to load 60k records whilst the 2 separated queries ran simultaneously takes 19 seconds to load the same number of records including the transformer combining the 2 queries on the users computer. In contrast, it takes 1.7 seconds to load the query with the inner join from mySQL workbench.
  4. Additional info: Retool Cloud. Server Side Pagination isn’t an alternative in this case because the end table is using group by.

Hi @Daniel_Fleuranvil,

A few ideas:

• Try selecting only the columns you actually need — avoiding SELECT * or returning 40+ columns can significantly reduce payload size, serialization & transfer overhead, which often slows down apps (if this is an option).

• If the data set is large and most fields aren’t needed up front, you could also split into a “summary” query + a second “details” query (or load details on demand) to avoid heavy data loads immediately.

• Alternatively (or in addition), using a DB-side view (or materialized view) to pre-join/filter data keeps the join burden on the database and makes Retool’s job lighter; fewer rows/columns flowing through the UI/serialization pipeline.

• Lastly, if you hover over the query you will see a breakdown which can really help knowing where any bottlenecks are. This is a screenshot of a screenshots query (ironically) with over 32,000 records.

Could you share the actual SQL query (or a simplified version) ? That would help us diagnose whether it's a DB, data transfer, or UI/serialization bottleneck.