I would like to understand a bit more about Big Tables on top of the documentation available. To give some background, my client use a Business plan. and currently use Glide tables. I was wondering whether it would be a good idea to move to Big Tables since they are in a Business plan anyways. One primary reason is that I will be able to filter queries while using GET rows. Since Glide tables returns all rows, I’m adding additional steps in Zapier and filtering out what I want. From a data volume perspective Glide tables is good enough though.I’m just trying to look ahead.
One more point is, I use a lot of Computed columns, Single value columns at the moment.
Are there any key points to consider and keep in mind while making a decision? Thanks!
I have worked a lot with Big Tables right from the start, so I feel like I can share a few things that I’ve learned.
My general rule of thumb is that I only use Big Tables for transactional type tables, where lots of rows are being added on a regular basis. If I expect the row count to climb above around 10k within a year, then I’ll definitely use a Big Table.
When opting to use a Big Table, you need to think carefully about how it will be used, and how it will interact with other tables in your App. It’s always better to use more non-computed columns than less. For example, I would never store a Users name in a regular table. Instead I’d store a UserID and then use a relation+lookup to get the name. In a Big Table I will store both the UserID and the User Name.
Whilst we don’t have support (yet) for all computed column types in Big Tables, this is being actively worked on. Right now we have support for Math, If-then-else, Template columns and perhaps one or two more. It is a stated goal of Glide to eventually remove the distinction between Regular and Big Tables, and I expect they’ll get there in time.
You mention that you use Single Value columns a lot. That’s not yet fully supported with Big Tables, so you’ll need to think carefully about what you will do there.
A combination of the Joined List plus a JavaScript column can be used very effectively to work around some Big Tables limitations. For example, where you might want to do some sort of aggregation that isn’t yet supported, what you can do is take a Joined List through a Query of all the values you want to aggregate, and the feed that into a JavaScript column. This technique has saved me on several occasions.
Overall, Big Tables are great, and I thoroughly recommend them
I have a couple questions about whether to go for Big Tables as well. I haven’t even yet diagnosed how many changes to logic I would need to make, since that will be a heavy lift.
How would performance compare in a Big Table with say, 2x the number or rows in a Glide Table? I’m considering an archiving strategy and regular Glide Tables as an alternative. Right now my two largest tables are in Google Sheets, so I’m going to have to deal with re-creating relations that use Row IDs.
How do actual table row counts factor versus app row counts on plan limits? I’ve been bumping into data problems in the editor as the app total crossed the 25K line, but no individual tables are over 8-10K. Does changing the largest table to a Big Table up the limit to 100K for the app? Sorry if this is laid out somewhere - I couldn’t find it.
Here’s another Big Tables question - what conditions lead to seeing “Query” in the data table? Just trying to get my bearings. Does the “More computed columns in Glide Big Tables” team setting factor in? Which columns are the additional ones available with that setting checked? I’ve read the list of limitations but it’s not clear to me how those limitations will show up in the builder.
Those are separate. Glide Big Tables, SQL data sources, and BigQuery are considered high-scale and their total limit is 10 million if you have access to them. Other data sources are limited to 25k on all plans.
If I recall right, any computed columns that uses a high-scale table in their configs, but I’m not entirely sure.
