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.
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.
Wouldn’t it be more cautious to say that Big Tables are the way to go if X, Y and Z?
It feels like you’re saying Big Tables “are the way to go but maybe not” in the same breath
I don’t understand the nuances, but Big Tables are not just bigger regular tables. They have limitations (which granted might also be the feature) which could be the reason exactly not to adopt them. I really think it depends on the use case.
Also, if something is achievable with Big Tables and requires advanced skills in Glide which the creator might not have, then that would also be a no-go.
I’m not contradicting for the sake of it, just adding information so that Werther can make an informed decision.
Why is this a strict limit now when it was a soft (softer, soft-ish) limit before?
There certainly doesn’t seem to be a ‘technical’ issue going over 25,000 rows. As I recall from previous discussions the apps don’t break. They may perform sluggishly/very sluggishly.
Probably partly to help enforce the pricing structure and force users to higher plans with higher limits on big tables…but also to suppress those that would complain about sluggishness when they blow past 25k records despite advisories against it. I wouldn’t be surprised if glide received a handful of complaints from people asking why their 50k, 100k, 250k glide table is causing the app to run extremely slow.
Yea but…..using row owners can dramatically reduce the number of rows downloaded to a local device and should (if performance is a driver of the limits) take that argument off the table.
In my case, I use row-owners heavily and would not expect any single user to exceed 5,000 local rows even through the App would have 50K-60K google/glide table rows.
Glide ‘row-owners’ is built for security and performance reasons and I would think should factor into overall ‘row sizing’ for an App.
My 2 cents: This is not a nuance; it is a feature of Glide and should factor into sizing.
I don’t disagree, but refer to the first part of my previous statement…higher price plans allow more rows.
Yes, row owners can drastically reduce the number of downloaded rows and counter the performance arguments, but the fact of the matter is that the data still has to be stored somewhere. What if you had a Maker plan, 1 million users (which theoretically is allowed if you don’t utilize a user table), and each user had 5000 rows. That’s 5 billion rows of data that is still being stored on Glide servers even though a user only sees 5000 of them. That’s a lot for a cheap plan and maybe runs glide into the red. I don’t know. It’s their business decision–not mine.
In my industry I work with billions of rows of data across thousands of tables, so yeah 25k is paltry in comparison, so I get it. Fact of the matter is that while Glide does enforce the 25k limit, they are pretty lax on the number of columns and the amount of data that can be stored in each cell (1 million characters). A little give and take in reality. Would you really want them counting cells or characters in each cell instead? I think they chose the number because it’s generally safe, and again helps enforce the different plan levels. All without scrutinizing the amount of data we store in those rows.
If your app approaches 25k rows on spreadsheet data sources, it’s probably worth making the effort to learn Glide Big Tables and their limitations. I’ve spoken to a few experts lately who build on Big Tables almost exclusively.
First of all, thanks so much for all this discussion! I didn’t expect that, you are the best! This community is the best!
To sum up, my concern is exactly what you all said, the dichotomy:
I’m afraid Glide will make my app stop working when reaching 25k rows to enforce the limits
2. At the same time I’m afraid Big Tables will mess up my calculations, making my app not so trustworthy
About the point #2, Glide isn’t helping to make me feel secure, because the documentation about Big Tables doesn’t match what the technicians/AI assistant tells me in the support chat.
@nathanaelb what did these experts who built solely on Big Tables say?
