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.