I want to make up my mind when it comes to the following problem.
I want to use Glide for a CRM solution, that might have a database of 10,000 to 30,000 “client accounts” (for now)
I started the implementation in Google Sheets, as I could use App Scripts to run multiple custom actions and scripts
I want to understand if my setup is sustainable when it comes to managing such a database, where actions might be run on multiple rows, given the policy that Glide applies to updates
Can you help me understand how updates are counted in some scenarios?
I run an action with an external tool and I have 300 new lines to add to the core table, how many updates is this going to consume?
I run an action to update field to all 10,000 rows at once. This could be adding one column to the Google sheet, running a simple function, like an “IF”. Would this consume 10,000 updates?
I’d appreciate some help in clarifying how this mechanism works, or what to do to “manage” the resource consumption
I run an action with an external tool and I have 300 new lines to add to the core table, how many updates is this going to consume?
Using the new Worflows tool, you will consume 301 updates: 1 to fire Webflow + 300 to add rows.
Although using the new API v2, add this quantity as a batch will consume 1 update.
I run an action to update field to all 10,000 rows at once. This could be adding one column to the Google sheet, running a simple function, like an “IF”. Would this consume 10,000 updates?
It will consume 10k updates if in your loop (workflow) one of your steps always updates the value of a row.
On the other hand, if there is a prior conditional (IF) and it is “true”, the final number of updates will be associated with how many times your conditional was “true” and rows updated.
But again, the new API v2 can do that job more efficiently if Big Table is your data source
Well, I’m creating a CRM that has a lot of entries
Let’s say up to 25,000
I want to have computed columns to see which rows fit certain criteria, eg. if they come from the Health Industry or whatever
I guess that adding this column in Google sheet would require 25,000 updates within Glide.
What happens if I add it as a Glide column within the Glide Table?
I will not renew the whole database very frequently (that’s where scripts come into play), but I do want to be able to compute stuff based on the existing values
Also, I’m thinking of segmenting my database into two parts, visible to Glide and not visible to Glide, to avoid consumption of credits
What do you think?
I have read the list of rules about “updates”, but I’m not 100% sure I understand what will count as an update (for now)
For the most part, computed columns do not consume updates. The only exceptions would be those associated with AI and some external integrations.
I would avoid that if possible, if for no other reason than to reduce unnecessary complexity. If users are just browsing your data, as a general rule that won’t cost any updates. Updates mostly come into play when adding/editing/deleting data, depending on which plan you use and which data source. One thing to keep in mind is if you use an external data source such as Goggle Sheets, then every CRUD action will cost you an update. On most plans CRUD actions do not count as updates when using native Glide tables. So for that reason alone, using native tables is a more cost effective option in most cases.
If use native tables, how can I bring external data to them?
Let’s say that I have 300 profiles to add (that I will be in any case collecting in a Google sheet). Is there a smooth way to import them?
Let’s say that I got new data for 100 rows that I renewed, or found new info, how can I edit the existing data? In the sense that I have to somehow filter the row etc
Would such actions work if I only use Native Tables?
I’m very familiar with Google sheets and the relevant backs and forths, which is why this was my original option!
Lets look at the case your database is Google connected to Glide:
-when Google script will add 100 rows it is more chances to take 1 update in Glide, because Google ask Glide to sync not instantly, but when Google think.
For now every day i rewriting whole Google table(5000) rows and in most cases it took one Glide update.
Every plan supports manual CSV upload directly via the Glide Editor, which does not incur updates. If it needs to be automated, then there is the Glide API, but that does incur updates - one for each add/edit/delete.
If you were using native tables, then you would just edit the info in place via the App, which (on most plans) would not consume any updates at all.
It is, but my earlier comments still apply. That is, any and all changes that you make via the App will still consume updates.
I guess it depends on how you plan to use the App. If it’s purely intended to be a read-only front end to your data, and you don’t intend to allow adding or editing via the App, then using a Google Sheet as a data source is probably fine. Just be aware that changes that are made in the Google Sheet will always take time before they are reflected in the App. Sometimes seconds, sometimes minutes. And this includes data that is changed/calculated via sheet formulas. You should absolutely avoid those as much as possible, as in most cases they will only slow down your App.
Same. I’m also a big Google Sheets fan, and I’ve been using them ever since they first became available around 20 years ago. But I very rarely use Google Sheets as a data source for a Glide App. I used to, perhaps 2-4 years ago. But not any more.
You mentioned the “via the App”. Does this mean that I do changes directly in Google Sheets, then those reflect as one update, as per slscustom.ru’s post above?
If yes, then this really clarifies the process. And we do have the “via the App” CRUD actions contributing to the update consumption.
Is it only performance, or are there more reasons that make you choose Glide tables over the combination with Google Sheets?
I am thinking of keeping the best of both worlds in my solution, given the pros and cons that I currently understand.
It depends. The way it works is when a change is made in the Google Sheet, Google will notify Glide that there has been a change, and Glide will initiate a sync. That sync will pick up any changes that have been made since the last sync. So if you are doing bulk changes in the Google Sheet very quickly (such as a search and replace or an import), then in most cases all changes will be picked up in a single sync and will incur a single update on the Glide side. But if you are just making ad-hoc edits here and there, then it is more likely that each edit could trigger a separate sync, at a corresponding update cost.
Performance, and power. Glide Tables and the Glide Data Editor are incredibly powerful. There is virtually nothing that can be done with Google Sheet formulas and Apps Script that can’t be done with pure Glide. As a general rule, there are only two reason why I will ever attach a Google Sheet to a Glide App:
if the data is absolutely required in the Google Sheet, due to some other external process, etc.
if I need to assign multiple roles to users, then I will use a single Google Sheet as the source of the User Profiles table (assigning multiple roles per user is one thing that can’t be done with native Glide Tables)
If I only use Glide Tables for an app, then the CRUD actions do not contribute to the number of updates. The actions that contribute to the monthly limit would be AI actions or other external actions/integration
If I build an app for a 2-day event with 1,000-3,000 users, can the above setup support my goal? Under the Maker plan, where unlimited personal emails are allowed.
You would know if an action consumes updates, Glide has a note/label for it when you add it to a workflow.
You must make sure to let them know they can only use personal emails, and maybe consider enabling unlimited usage if the base updates count might not be enough for the whole event. Maker gives you 500 updates + 2 cents/extra update.
