So protected columns data is not downloaded to a users device. I see many threads about using row owners for app performance, but aren’t protected columns as useful?
Protected columns are a great way to keep unused columns in your data source secure. They are not as useful for performance as Row Owners, as they do not restrict access to data. Row Owners allow you to restrict access to certain rows, so that only the users who own those rows can access the data.
This link could be useful: Glide Docs • Protected Columns
This is an experimental automatic reply from a bot. Please like it if the answer is correct.
2 Likes
That’s a pretty good answer from the bot 
Protected columns won’t really help with performance, as they won’t prevent rows from being downloaded.
Imagine that you have a table with 10,000 rows and no row owners, and 1 protected column. Every user device will still get all 10,000 rows. They just won’t have access to the data in one column.
But let’s say you apply row owners to that same table, and you have 100 users that each “own” 100 rows. Each device will download only 100 rows, and so the performance impact will be much greater.
1 Like
Thanks Darren, we fully understand the benefits of row owners. Definitely way more important than limiting columns.
But the question is we have users that own 5000 out of 17000 rows.
Protecting 30 out of the 50 columns in the app (mainly used by another app), shouldn’t that improve their performance significantly?
Glide documentation says data in protected columns is not downloaded on the user device.
We could be improving performance & reducing downloaded data
To be honest, testing some of these apps on 5g, I’ve consumed my monthly data packages in hours
Okay, yes. That could help - especially if those columns contain a lot of data.
The important thing to keep in mind is that once you protect a column it can’t be used by the App.
It can be written to via a form, but the data written won’t be accessible.
If you have a majority of columns in a table that aren’t used in an App, I can’t help wondering if it would make sense to refactor the data a bit - split into separate tables? May or may not make sense in your case, but perhaps something worth considering.
3 Likes
Most our data is orders data. But for example in our partner app, they don’t require any data regarding order processing, shipping, customer info etc… all they need to see is the item data