When I first started my app I wasn’t very conscious of the key decisions I needed to make when creating new tables. As a result, all of my tables are sheet tabs rather than glide tables. As the app scales up I’m becoming more conscious that at some point I’m going to have an issue with 2 tables specifically that could potentially blow out my 25k limit.
I see some posts and feature requests about converting sheets to glide tables but they’re a little old at this point. And also some comments that creating a glide table and manually loading it from the existing sheet will break all of my links in the existing app screens.
There is no easy way to convert a Google Sheet table into a Glide table.
But… if your only reason for doing that is to minimise your row count, then you’re barking up the wrong tree
Glide table rows count exactly the same as Google Sheet rows when it comes to row count limits.
In fact, if you’re concerned about row limits then you are better off with Google Sheet based tables, as it’s much easier to move rows out of a Google Sheet than a Glide table.
I guess I feel now is the time if I do need to get some data out of sheets and into glide tables. I’m happy with the app as it works now but how will it look/function in 5 years? I keep reading that 25k rows is actually ok as long as your app isn’t overly complicated. I’m not sure mine would fit that description though. It’s essentially an event register. I create a team and that team has members (user signs up and then joins a team). The teams have associated events that the team members can then confirm or decline their attendance to. Approx 100 members per team. Currently only a handful of teams but I expect over time there could be a lot.
As a note on above….attendance is recorded using an array vs the event and not a new row entry in a sheet (to try and reduce the number of entries)
I feel like I could get lots of users if I wanted them so the question really relates to a longer term strategy around scalability.
How many users could I add before I need to throttle back? There’s quite a bit going on in the app but the 2 tables I’m concerned about are the users and events.
A lot of what’s written above is just me getting it off my chest and writing it down. Appreciate you listening if anyone got this far I’m sure it’s not unusual and many folks here face the same question. And obviously I’m conscious I actually need to get to a point where I’ve got enough users to hit the wall. But no point crying about it then. Better to plan for it now. Or at least understand the limitations.
It would be possible to flush out old users and events periodically so maybe staying on sheets makes more sense from that perspective.
I have an app that fluctuates between 20-30k rows. It’s a mixture of Google Sheets and Glide Tables, but all of the tables that are heavy in transactional data are sheets based. I’ve been able to create automated processes that periodically summarise the transactional data and archive old rows. With sheets based tables, that’s relatively easy to do. With Glide Tables, it would be much more of a challenge.
Glide do have an API available now that could help with that, but for now at least that’s an Enterprise only feature.
I would create a table v2.0
That means you continue to edit the old as before but the new are in a different table.
If you are in need to access both the versions from the same functionalities, then you should distinguish in advance if the record is old or new (means you can put in a join field all the old ID and if the id you are going to use is CONTAINED in this list then you access the V1.0 ELSE the V2.0.
Obviously you should put this in all place where those tables are used.
This is the best i can think with no elements in my hands
I’m sure it’s not unusual and many folks here face the same question. And obviously I’m conscious I actually need to get to a point where I’ve got enough users to hit the wall. But no point crying about it then. Better to plan for it now. Or at least understand the limitations.