I am making a learning app that I want to be able to scale to around 25k users.
Most of the content in the app, users will be interacting with passively so performance wise, there shouldn’t be a problem (tables (for example courses) will have only a few thousand items max). Also, for security reasons, any content people add will have them as a row owner so they will only download their own data.
However, I have one Table (Task fulfilmments) in which users themselves will generate a lot of items. A few hundred to a few thousand per user.
The logic thing would probably be to make this Table to be a Glide Big Table. However, I am missing some functionality (rollups against relations, search in computed columns etc) which still leads me to using normal Tables.
My question is: given that I use row owners for any content created by users, will a normal Table be able to scale to hundreds of thousands of entries (because each user will only download a small fraction of that), or will everything go bonkers and should I use a Big Table, thereby losing some functions.
I should note that I have one admin account which can see anything, I can imagine using this account will become impossible once there are too much entries in the Table?
Note: the app will be offered by a company to all of its clients (currently 1000 and growing with 100% each year, therefore the need to allow for 25k of users)
I’d be interested to hear more about this too as I’m also working with a large-scale user base.
One of the reasons I’m not transitioning to Glide Big Tables straight away is due to the refresh rate.
Theoretically I think that’s exactly how it will work, since Glide will “scan” the database and apply row owners/roles to that, before letting the user download only what belongs to their account.
In your admin case, if all rows can be seen, then all rows will be downloaded, and I think it will cause performance issues, especially if it goes over 25k.
Naturally, Big Table is the answer, but as you noted, it can come with lack of functionalities compared to the normal table.
@ThinhDinh : Thanks for the answer! So the app will probably be usable for users, not so much for an admin who sees everything.
Finally: given that you also see all data in the Glide App Edit screen, I guess editing the app will become impossible too beyond a certain number of rows, even when using Row Owners.
I haven’t had that many rows to deal with recently, so I would leave that to other people to answer. I guess they must have taken that into account when they announce Big Tables.
Rollups against relations (and queries) are now supported in Big Tables, as long as the target column in the Big Table is not a computed column.
The answer to this question is kind of moot, because there is no Glide Subscription Plan that currently supports this. The extended row limits that you get with Business and Enterprise Plans is only for Big Tables. For all other data sources, the row limit per project remains at 25k. I don’t think that’s currently enforced (at least not on Enterprise), but that doesn’t mean it won’t be in the future.
Okay thanks! So, using Big Tables will still be the best solution! Gotcha Expanding tables much beyond the 25k limit is not best practice right now and will lead into experimental domains!
Expanding tables much beyond the 25k limit is not best practice right now and will lead into experimental domains!