How scalable is Glide

One of the scenarios is like this where delayed update causes not-so-great experience for my users.

  1. Screen A: User selects a payment plan (choice component) and taps “Purchase” (buy) button.

  2. Goes on the checkout page and makes a payment.

  3. Comes back to screen A where user should see “Payment done” label and the choice component shall become invisible. I wrote a script on insert in “App: Sales” sheet which updates certain fields. Then I use these field values and conditions. But it does take time for the update trigger to fire and show these changes on the screen.

I don’t know but may be an App is allowed a pull update check trigger then this can be fixed. I am thinking in the UI editor where I would expect this trigger but in my case after the checkout screen closes I expect this to happen.


How does the 25000 limit relate to user profiles. If you have 25000 users, will the user profile sheet then overwhelm the app?

If you have 25000 user rows then it will become a problem but they’re testing Glide Sheets in staging, which doesn’t use Google Sheets as a source so hopefully that bottleneck will be gone.

1 Like

How soon is that estimated to be available? I’m thinking of using Glide to make an enhanced viewer for a back-end system that already has 160K users.

Not sure, but as it’s already in staging, if they don’t see many problems then I expect it to be in production in the next weeks.

1 Like

I still can not understand how app can have 100k users if the any user is a row in sheet.
Can you explain how many many users can use the app with personal log in

There is no good answer to this. Glide does say there is a 25k row limit, but I don’t think it’s strongly enforced. As long as you structure your app with Row Owners, then you shouldn’t have a problem. If you don’t use row owners, then each user will be downloading data for 100k users, which could cause it to run really slow. If you use Row Owners, then each user will only be downloading their own data.


Ok but then if the app has 200k products that are visible to every user, does this mean that every user will download 200k rows data?

Do we know by now if GlideSheets solves this?

I would have to assume that yes, each user would then download the data for all 200k products.

Hard to say how much of a difference it would make to use glide tables in place of google sheets. It will definitely eliminate the sync between glide and google, but you still have the sync between glide and the user.

I’d say to try it and see what happens. When I tried 120k rows last year, it was slow, but I also wasn’t displaying anything very efficiently. I was simply trying to load all 120k rows in a single list. I’m sure there are a lot of variables to consider, but in the end, it’s my understanding that all or most of the data is synced to the device when it’s opened.


Just checking I’ve understood the discussion so far - it sounds like the 25k row limit is per user so if I was using row owners and had 2 users with 25k rows each, that would be fine for the Pro plan?

25k is the technical “limit” for the all of the data in the app, but it’s not strictly enforced by glide…yet. It’s more of a technical limit when syncing data between google sheets, the glide database, and the copy of the database on each user device…along with any necessary computations that need to happen for each row.

Your assumption of 25k per user depends on how your data is set up. If you do not have Row Owners enabled, then all data is sent to, and cached, on a user’s device. That can become a lot of data to download and can slow things down. If you are applying Row Owners, then only the owned rows are sent to a user device, which can greatly help with speed depending on how many rows a particular user owns.

The 25k limit can also factor into the sync between glide and a google sheet (if you use google sheets as opposed to glide tables). The sync between glide’s copy of the database and the google sheet can become bottlenecked if there is a lot of data to move around.

In your case, as it stands right now, you should be fine depending on how complex your tables are and how many computed columns and relations you are using. Every time you open the app, it has to first download the latest data, and then run through any computed columns and build relations. This is usually the biggest culprit for speed issues. User devices are doing almost all of the calculations against the data. Glide will allow you to have a total of 50k rows and even more, but it can start to affect any syncing as well as the builder (which will load and process all data regardless of row owners and which user you are previewing as at the time).

I think the bigger concern is how complex your data is. I have an app with around 8500 rows total and primarily one user that generated most of that data. So row owners is irrelevant for me and not something I want to use if I later want to grant all other users access to the same data. The app itself loads quickly, but one tab in particular is very slow to load initially. Right now it takes about 30 seconds on my device for that tab to load. A subsequent screen beyond that takes another 10 seconds to open. After that initial load, it works normally but there’s awhile to process the data initially. I’m pretty sure it’s a combination of several calculations that have to run on all 8500 rows, so dependent computed colomns can then be built, and then dependent relations can be built. I’ve come to realize that some logic needs to remain in the google sheet to help maintain speed of the app, but I’ve been trying to make this part of my app more efficient for a couple of years now. I also think the speed issues are largely due to the calendar style layout. I prefer the calendar layout and other layouts haven’t been satisfactory for my user, but for some reason I can’t limit how many calendar rows show on the screen like I can with other layouts. I can filter, but then that restricts my ability to use the built in search to search through all of the data. Plus, it’s probably doing some complex sorting behind the scenes to sort in date order. This is one of those cases where I wish it was more clear on how glide works on the back end and how it processes data and actions. It’s frustrating to not be able to debug the code and see how it works, so I can figure out where my bottlenecks are.

Sorry, that was a side rant, but the point is, that the amount of data isn’t always a factor. It’s how much computing power is needed to process your data within the app.


Never thought that layout could affect load time…

That’s been my observation. Mainly just with the calendar layout, and probably when I’m trying to load such a large number of rows at once. I’m guessing it’s structured differently from other list layouts. For some reason we don’t have the option to limit the number of rows without using a filter, like we do with every other list layout (trying to avoid filters because it requires more computed columns to build the filters). I’ve tried to reproduce the calendar layout with grouping and cards. It loaded faster, but just didn’t look and work the same. Maybe I could try again and go nuts with CSS to see if I can get closer to the calendar layout. I just keep trying to make things simpler instead of more complicated, while maintaining existing app functionality. Still learning.


Beyond your Glide skills of course, your humility is impressive, Jeff.


Calendar layout does not virtualize and is known to have performance issues with large amounts of data. It should be used with pre-filtered data or small data sets only.


I’m getting something pretty convincing with a cards style layout, grouping, and some CSS.

So when you say “in the app” do you mean that, that’s the (soft) limit for the maximum amount of data that can be synced into a user’s device or the maximum amount of rows of data that can be stored in the Google Sheet / Glide database for all users?

I’m doing all of my calculations in Google Sheets right now so it sounds like I won’t have a lot of issues with syncing. After initially syncing quite a lot of data to the user’s app, generally each session won’t need to retrieve many new rows and the data that’s being synced over is pretty simple so hopefully I’ll be ok. I am doing some sorting and filtering in the app but that’s about it.

Thanks for the heads up about calendar views and for the detailed answer in general, I really appreciate it!

1 Like

Very impressive when the CEO is on a forum answering questions!

In this context, I was referring to all of the rows in the database, for all users. Not necessarily all of the rows that will be downloaded to a user device.

The problem with this question is that there is no one answer. There’s just too many variables to consider.
Glide does not impose hard limits as of now, but always be prepared if they happen to make that a hard limit in the future. Beyond 25k, and you may be on your own to figure out any speed related issues. You could definitely have 200k rows and each user owns 100k rows. It might work just fine or it might not, depending on complexity and the flow of your app.

The important thing to know is how the data is moved around and handled. This is not a typical server/client situation where the client requests certain pieces of data from the server. Instead, a full copy of the database is stored not only in the Google sheet, but also on Glide’s servers, and also on each user’s individual device (minus any unowned rows). So, if you have 100 users, expect 102 copies of that data to be in existence. The individual user devices then synchronize data between the app and Glide’s servers. Glide servers then synchronize between the server and the Google sheet. User apps will never have a connection or know the existence of Google sheets, and vice versa. Only the glide server knows the existence of both. How much data are you willing to move between google and glide at any one time? How much data are you willing to move between glide and the user device at any one time? When it becomes a lot, and much more than is supported, or more that an internet connection or device can handle, then you will have sync or speed issues. But there’s just too many factors to pinpoint what may constitute a “limit” that a device can handle.

In the app I mentioned in my previous post, I did some work on my app and I got my user’s phone to load the problem tab in about 7 seconds. That’s on a 4 year old Samsung that was premium at the time. My 2 year old cheapo Motorola loads the same tab in 30 seconds. Only 8500 rows, but a lot of gross inter-relation linking of tables. My app in it’s current state wouldn’t survive 15k rows, much less 25k rows…but that’s my problem to figure out because of how complex I’ve designed it. A much simpler app would have no problems going well over 25k if it’s designed efficiently.

I also want to add, you will most likely have a full resync of data every time you open an app on a user device. The db copy on a user device seems to be temporarily stored in a user’s cache while using the app, and only syncs changes…but that DB is rebuilt after you close and reopen the app, so it has to re-download all data again.

In the end, I’d say just test it yourself. Keep duplicating data until you reach 25k, 50k, 100k+ rows and see what your app does. That’s what I did a while back. I wanted to see how an app handles large sets of data, so I created a sheet and started duplicating rows and testing over and over again, until I reached 120k rows. The data was simple (a couple of columns), and the app got really slow, but, in my case I was also trying to display 120k rows in a single inline list. That’s a lot to render on the screen at once. It’s better to just test with your specific app flow rather than speculate and guess what may or may not happen once you reach that point. It’s easy to generate and delete fake data if you are using Google sheets.


I see what you mean but your answers have given me a great sense of what to consider here so thanks again.

Each of the users of my app will have 10k+ rows each so Glide’s obviously not the right solution in this instance but at least I know that now.

1 Like