# Performance: Glide Table with Row Owner vs Big Table

**URL:** <https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324>\
**Category:** Ask for Help\
**Created:** [May 31, 2023, 4:46pm UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324 "2023-05-31T16:46:50Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Flowcode](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/flowcode/32/64316_2.png) [@Flowcode](https://community.glideapps.com/u/Flowcode)\
**Post date:** [May 31, 2023, 4:46pm UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/1 "2023-05-31T16:46:50Z")

</div>

Hi there!

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?

Thanks for the input!

---

<div class="post-metadata">

**Author:** ![Flowcode](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/flowcode/32/64316_2.png) [@Flowcode](https://community.glideapps.com/u/Flowcode)\
**Post date:** [May 31, 2023, 4:47pm UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/2 "2023-05-31T16:47:50Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![Sebastian\_H](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/sebastian_h/32/57533_2.png) [@Sebastian\_H](https://community.glideapps.com/u/Sebastian_H)\
**Post date:** [May 31, 2023, 6:33pm UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/3 "2023-05-31T18:33:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ThinhDinh](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/thinhdinh/32/49_2.png) [@ThinhDinh](https://community.glideapps.com/u/ThinhDinh)\
**Post date:** [May 31, 2023, 11:49pm UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/4 "2023-05-31T23:49:26Z")

</div>

> [@Flowcode](#):
>
> 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)

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.

 ![image](https://us1.discourse-cdn.com/flex002/uploads/glideapps/original/3X/e/0/e03fe6d3e27981109f2e32044068c0b0864d97ed.jpeg)

---

<div class="post-metadata">

**Author:** ![Flowcode](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/flowcode/32/64316_2.png) [@Flowcode](https://community.glideapps.com/u/Flowcode)\
**Post date:** [June 2, 2023, 8:49am UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/5 "2023-06-02T08:49:57Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![ThinhDinh](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/thinhdinh/32/49_2.png) [@ThinhDinh](https://community.glideapps.com/u/ThinhDinh)\
**Post date:** [June 2, 2023, 8:52am UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/6 "2023-06-02T08:52:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Darren\_Murphy](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/darren_murphy/32/47326_2.png) [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)\
**Post date:** [June 2, 2023, 9:15am UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/7 "2023-06-02T09:15:45Z")

</div>

> [@Flowcode](#):
>
> 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.

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.

> [@Flowcode](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![Flowcode](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/flowcode/32/64316_2.png) [@Flowcode](https://community.glideapps.com/u/Flowcode)\
**Post date:** [June 3, 2023, 7:18am UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/8 "2023-06-03T07:18:07Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/system/32/53398_2.png) [@system](https://community.glideapps.com/u/system)\
**Post date:** [June 4, 2023, 7:18am UTC](https://community.glideapps.com/t/performance-glide-table-with-row-owner-vs-big-table/62324/9 "2023-06-04T07:18:57Z")

</div>

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
