I have an app with multiple Google Sheets. One of the google sheets has about 50 columns and there are about 120 columns in its connected glide table (the extra columns are calculation columns inside the table)
I would like to know how many rows could be added to the table/sheet before the app starts stalling, slowing down or just operating inefficiently or worst case bombing out altogether.
I believe the new row limits for apps are 25K and 50K for pro or biz plans but i’d still like to know whats the optimal size for the best efficiency and if anyone has actually stress tested their apps at scale and still maintained a pleasant user experience.
There’s no easy answer to this question. There are way to many variables to consider. It can vary based on your computed columns and what they are doing. The best way to test it is to do it yourself. Load up your table with a bunch of test data and see what happens.
2 Likes
Okay thanks Jeff, i’ll try that👍
1 Like
My app performance starts to clearly slow down around 14-15k rows.
by then, you would probably want to deactivate Glide’s built in search bar and avoid using the big sheets as sources for tabs.
I do however probably have double your column count and with the new announced Glide changes on apps, I assume they should start performing significantly better (similar to pages)
If you could, use row owners to limit the number of rows downloaded on a users device
3 Likes
Thanks for that info, very good to hear. I’'l experiment with row owners, never tried that before. I think that could be possible with the app i have in mind, thanks again👍
Interesting!
Have you tried to load your 14-15k rows directly (raw data) without using any relation or computed column? Of course, you need to have a Pro plan to do this kind of test. 
Saludos!
1 Like
I have always thought that the main problems with an APP that handles large amounts of data come from:
-
Too many columns in the same table. A table with 15k rows can perform well if it has up to 10-12 columns, but when it has more than 30 columns there is no way to maintain/improve its performance.
-
I prefer to split my data into multiple tables to avoid having as many columns as possible. I prefer to have many small/medium tables than 1-3 huge tables with many columns.
4 Likes
We’re on a business plan currently.
Yes i’ve tried loading the rows without any relations & computed columns on a new app. The app performance and is obviously better. However… its hard to build apps without relations and computed columns 
yes for sure the number of columns especially computed ones does definitely harm the performance, though there are some things I’ve realized that make things better. For example good use of relations actually is better than reducing relations. For example an orders table with 12.000 rows. instead of creating a tab based on that table and using filters to show a portion of the orders. I have a tab based on a 1 row glide table… which performs a relation and that performs way better in the app.
that I don’t really like honestly. Its also not possible in our case.
4 Likes
I concur this. Not just the app but the builder as well. Hopefully the new computation model solves part of this.
1 Like
Of course! 
My goal was to indicate that the theoretical limit of “25k rows” depends on other factors, the quantity of columns also hit this performance.
I have 2 APIs with almost 50k rows running, one has 7 columns and the other 38 columns.
The first one replies in 3-4 secs any request but the 2nd one lasts 7-9 secs. 
Saludos
2 Likes