Hey, guys!
It’s been a long time, I miss this community!
I built my app using solely Glide Tables. When I started using Glide, Big Tables wasn’t a thing, so I was not very familiar to them when I built my app.
Now, 1 year after my app’s launch, I’m reaching the dreaded 25k row limit.
After researching and a long thought process, I came to the conclusion that migrating my current data from Glide Table to Glide Big Table is my solution. Do you guys agree?
Also, any suggestions and/or warnings to make this transition work?
The app is working so fine the way it is, I’m afraid to break something 
If the app is working fine the way it is, I would continue using it as is.
As for Glide Big Tables, my understanding is that they do behave differently. Make sure you do your research in Glide Docs and the forum to clearly understand their limitations. The impression I get is that Glide Big Tables are suitable for data logs and not suitable when a lot of computation is going to happen, especially relations and queries. But I don’t know nor understand the details.
Oh, I see. Thanks for the heads up!
But how can I continue to use the app the way it is if when I reach 25k rows it will stop working? I’m already at 22k rows and freaking out about it 
Up until now, plan limits were loosely enforced. Rumor has it that limits will be more tightly or even strictly enforced this year (2026), but please don’t quote me on this, there are gaps between what I hear, understand, retain, and recall.
There are a lot of in-depth discussions about Glide Big Tables in the forum. I think I recall Darren M. crafting a comprehensive list of their benefits and limitations.
If I were to rebuild portions of my app against a new table, I would build sections in parallel to the existing functional parts of the app. I haven’t gone from glide table to big table, but I have converted from google sheet table to glide table in a live app without the users noticing, and then switched over to the new screens when ready by changing some visibility conditions.
Add the big table and get all of the columns set up. Add screens/tabs to your app that only you can access. Build them out using the new table while comparing to the old take and screens. Go through column by column in the old table, find uses, and make sure the columns in the new take are performing the same functionality. When you are ready to switch, you can export data from the old take and import into the new table.
Tedious…yes, but also gives your a chance to revisit old logic and improve.
The other option is to duplicate the app and rebuild against a new table, but it’s a little now work to switch over to a completely different app. Your call.
Big Tables is the way to go. The main problem is with calculations. I have migrated 2 apps like that recently, and it’s not a nice experience.
I would suggest building sections in parallel like Jeff said. The fact you can have two windows of the same app opened on the same device now helps.
1 Like