You can transfer the data easily enough - CSV import/export is probably the simplest method. But you’d have to recreate any computed columns and reconfigure any components that use the table. Keep in mind that not all computed column types are supported with Big Tables.
4 Likes
Thank you
Can we shine some light on these limitations with this release? Thank you.
1 Like
The docs are (almost) up to date with regards the limitations.
The only thing that’s changed since the docs were last updated is you can now do Joined Lists of non-computed columns into Glide Big Tables (this was literally released just a couple of days ago).
3 Likes
Are they planning to bring Big Tables to Classic Apps?
I seriously doubt it.
Perfect! 
But The issue is, can the apps handle it ?
my apps, after 5000 more record, it seems to be laggy, and slow loading
Are these apps built on Glide Tables or a 3rd party db like Google Sheets? Also depends on what you’re doing with the data.
Big Tables are inherently faster because the calculations are done server-side, not on the device
now im using Glide Table (Glide Pro), since google sheets took a toll of usages whenver a changes occured.
i thought maybe a lot of computed column in one table could cause the lag. is that true ?
Actually, strictly speaking I don’t think this is correct 
Computed columns are still handled client-side, the main performance benefit comes from the fact that the client only has a small subset of the data at any given time, with additional data fetched as required.
And as I understand it this is why providing support for all computed column types has been a challenge. For example, the Single Value column is not supported (and probably won’t be). That makes sense when you consider that in order to calculate Single Value → Average (for example), the client would need simultaneous access to the entire dataset - which it doesn’t have.
3 Likes
can i assume if the more computed column, the more resource need to be run in client devices ?
thats what make the app run slow ?
Ya…you might be right. I might have misunderstood a message from @Mark about GBT and it’s improved performance—might just be for API calls:
2 Likes
Yes, no, maybe.
There is no simple answer to that. Yes, computed columns consume client resources. But for 99.99% of uses cases the performance impact should be negligible.
Since i just migrated from Glide Classic Apps (Used GSheet and 4 different Table)
in Glide Apps, used glide table and merged 4 table into 1 since all of it related
and most computed column also in 1 table,
i guess thats what make it so slow ?
I agree.
If now, we have to load a subset of data to work with it on App, the response speed will depend on our Query and how it was written. I mean, if I have a table with 40k registers (rows) and 50 columns, an inoffensive Query like this:
Select * from MyTable
will be slower and more inefficient than this:
Select column1, column2, colum5 from MyTable Limit 25
I think that GBT and Firebase (GT) are column-oriented databases (NoSQL) so, our Queries have to be smarter and specific when those are written. We need to avoid the “brute-force searching for data” from now on.
Saludos!
2 Likes
That’s a good habit to get into.
Selecting everything from a table works in development. Not so much for published apps. 
It’s like someone asking for a spoon, and you bring them the whole utensil drawer.
2 Likes