Extremely slow load time for 41k GDE rows

My app’s URL: www.trainwithmit.com

Any help would be GREATLY appreciated. I have built a marathon club app with about 366 active users logging 5 runs per week. I’m using the GDE for this information and the app currently takes almost a minute to load a users recent workout entries. Is there ANY way to speed this up?

I’m not sure it would help and is it too late to do this but you can try using a Glide Sheet, perhaps?

This means you are loading all data for all users. Please use row owners to only load data per user.


I’m currently using glide sheets.

Will this allow all users to see recently logged workouts by other users?

Do they need to access all 41,000 rows? How many other users does each user need to see?

1 Like

Each user has a profile tab with their latest workouts and a community tab that shows recent workouts by ALL users. Before assigning row owners, will row owners destroy the community tab?

Well crap. Just looked into row owners and it doesn’t seem possible to have a community tab displaying all user’s workouts AND solve the loading time issue.


I got the go ahead from the client to use row owners to fix the loading times but the workouts currently use member ID’s and not email addresses. “Single Value” and “Lookup”columns can’t be row owners so how do I do this?

Correct. Row Owners would destroy the community aspect. You do have to consider that the app has to download and store all 41k rows in temporary cache storage. This can eat up a lot of device RAM, which will cause slowdowns as it reduces the remaining RAM available for the app to run. I know this might not sound ideal, but my idea would be to consider downloading a copy of the data and build it into a google sheet. Then apply Row Owners to the data to reduce the amount of data needed to download. Then maybe come up with some back end sheet logic to try to condense all of the rows into an abbreviated version to use for the community functionality. Something like recent data only, or grouped and summed condense data.

For your last question, correct, row owners need to be a basic column. Computed columns like Single Value or Lookup are computed on the user’s device. Allowing computed columns to be used for row owners would defeat the purpose of row security as all data would still have to be downloaded to the user’s device for the computed columns to determine row owners. At that point it’s too late as a savvy user already has access to all data. Again, if you had this in a google sheet, it would be easy to use a VLOOKUP formula to temporarily lookup all the user emails, then bulk copy them into a static column. I’ve done something similar when I converted a bunch of sheets keyed off of name to instead use ID’s. I’m not sure how to approach this with a glide table. It would be nice to be able to use Row IDs as row owners, much like how Roles or anonymous emails work. That way rows could further be secured without having to include a visible email on each row, and it wouldn’t violate the private-only nature of Roles.


You could use FILTER in Google Sheets to create a read-only table with just the workouts logged in the last 24-48 hours, then load this table for the community aspect. Then you’re not downloading all workouts just to show the recent ones.


Interesting challenge!

Is there a view to have computation sit in Glide tables as well as on the device at some point? Guessing a lot of the costs come from the back and forth with google sheets, and with the recent webhooks/ APIs, feels like we’re pretty close to not needing gsheets anymore.

Love the Row/ Customer ID as a row owner idea, I use the array Email 1, Email 2 trick in gsheets, but would be nice to not use customers emails anywhere in the app.

1 Like