Do Glide API calls count towards any quotas? (I’m on a Pro Team subscription).
Thanks
I believe only if you are adding, deleting or editing a row via API will it count toward updates
Correct. With Adding/Editing/Deleting, each mutation counts as 1 update. That is, if you delete 100 rows, that’s 100 updates.
I recently started my first app using solely Glide Tables, and I was excited about cutting out Google Sheets where possible.
Now it occurred to me that I used to interact with the Google Sheets API a lot! Using Make.com I would constantly be getting and posting data to the sheet without any charge from Google. My understanding is that GS was the major cost for Glide so I was excited about the Glide Tables API.
Now I’ve moved to Glide Tables for my next big apps and the Glide API is going to count towards the quota. I think I get the justification for the charge, but at the same time, I’m worried that the cost of running a good app is going to skyrocket.
I can’t make sense of going from a couple of ‘legacy Pro’ apps (I can’t remember how many updates/sheet edits it included, but I’m sure way more) to Teams Pro only allows 10k updates across all apps. I thought that if GS was the major cost and Glide Tables was supposed to be the new-and-improved low-cost data source, we should see the benefit.
It makes sense that the cost of the API is accounted for in the tier’s cost, as you cannot get access to it at starter, then only some of it at PRO, then advanced access in Business. Would changing the Glide API calls quota from a count-quota to a time-based quota like GS API be fairer?
1 Like
I’m not sure it would be fairer for Glide.
For Google Sheets, every time it tells Glide that there is an update, then Glide syncs back the data, and it costs them something, so under the hood, they still charge based on “updates”, in this case Google Sheet’s notice.
For the “extra” mode related to Sheets, they sync every few minutes regardless of whether there is an actual data update or not. In this case, Glide is charging for updates they initialize from their side.
For Glide Tables, every time you add/edit/delete something, it’s an “update” call Glide make to Firebase.
Hence, in all cases, I still think it’s “count-quota” under the hood. I’m not sure if there’s a better way to do it.
1 Like
I think that’s part of what I’m getting at. My goal is to use Glide Tables exclusively, as a result, I’m saving Glide a lot of money. Although now I’ve ‘upgraded’ to PRO teams I have only 10,000 updates for $99 vs [yet untold amount 
but definitely more than 10k] for $32.
I get that I can now have 3 white-labelled apps for that amount and I will definitely use that, but then that’s only 3.3k updates per app… The math just doesn’t seem right and it seems so much more expensive to do what I assume Glide prefers me to do, which is use their tables.
Another thing I just spotted is that the Pro Teams package allows up to 5k public users per month, which implies 2 updates per user, per month.
I’m just making observations at this point. I’m hoping I can get some pushback because the pricing structure of the API seems way off the mark, especially in comparison with what the update charges used to be on GS updates.
I don’t think this is a given. “Their” table is still costing them money since it seems to be hosted on Firebase. There are still calls to be made. It would improve your projects’ performance, but if you do a lot of updates that would still cost them money.
It allows 500, not 5000.
I can’t speak for Glide here, but I believe their old pricing structure doesn’t reflect well what cost them most, which seems to be updates, so the new pricing, whilst still controversial in this forum, reflects that better, in Glide’s view.
1 Like
I am certain of this…
I’m also certain of this! 
Without a shadow of a doubt.
As far as I can see, nothing is given. This is all I could find to go off:
I’ve had to make a set of assumptions. One is that the Glide Tables are the less expensive alternative to Google Sheet, which is the major cost to Glide.
I was able to make this assumption when I discovered the disclosure about GS updates costing them more than a Pro subscription. My concern I suppose is regarding how drastic the change in quota appears to be given the evident reduction in cost.
I guess at this point in the conversation I still don’t understand it. So many questions come out of it.
- Is add/edit/delete via the API the same cost as it is doing it directly in the table?
- Is the cost of an update via Glide API to the Glide Table the same cost as an update to GS?
- Are the methods above distinguished in the quota? E.G. API counts against quota, and direct in the table doesn’t count against quota?
- If Glide Tables are supposed to be the data source that is less expensive than GS why are users receiving significantly fewer updates/edits?
This is awkward… Not sure what to make of it.
1 Like
Basically if you add/delete/edit data in a Glide Table or Google Sheet, whether its via a form, text entry, Make/Zapier or Glide API, it will cost 1 Update per change.
Using Native Forms and Edits will result in only 1 Update regardless how many Columns are changed at once.
Custom forms will cost 1 update per column, meaning if you’re changing 10 columns in a single row, it will cost 10 updates.
With our new integrations, some of these cost more than 1 Update to run.
Keep in mind, there are no Updates when testing/building app in test environment, which I am sure costs Glide $
1 Like
This has changed recently, but the change only affects new subscribers - those that subscribed after the change was made.
1 Like
Thanks for such a quick response.
I should have been clearer. When I asked about cost when discriminating between different types of updates, I meant the cost to Glide.
The point I’m trying to circle in and understand is if Glide has been able to engineer (brilliantly I might add!) a lower cost and all-around better data source, why am I experiencing movement in the opposite direction with a more restrictive quota, whilst simultaneously having to pay more?
I guess only the CEO could answer that question, but probably wont due to the sensitivity of business.
My guess would be:
A) they were losing money and this new method reduces costs and/or increases profitability.
B) they repriced the product in line with competition
C) they were losing out on valuable revenue for larger clients who were getting a $10k/month product for $1k/month
But at the end of the day, its business and were consumers. We can freely choose to determine if the product is worth the cost. If it is, we stay and if it isnt, we find an alternative.
2 Likes
Yeah I think you are on point with those assumptions, it’s what I felt when there’s the price change, and reading comments in here about that.
Interesting point, although I’m not really interested in getting sensitive business information, only at the level that has already been discussed.
Answers to the degree of detail on what costs more or less were all I asked really.
Thanks for guessing…
This is absolutely correct, I’m not averse to the economics of business. Although I happen to quite like Glide and I’ve invested a lot of my time using it. Believe it or not, I’m first interested in conversations that help illuminate improvements for the future, before being interested in leaving the playing field.
Did you go on and move to Glide Tables for all your projects?
In my apps we have to delete a lot of data every day. For the reasons above and other reasons, I don’t feel confident switching my data source from Google Sheets to Glide Tables…
whats your advice on that after trying both?
I have done. It’s not looking great for that I’m afraid. I wonder if there is something in the pipes to be able to edit/delete multiple data rows 
You can delete multiple row’s through a relation.
1 Like
I’m staying with google sheets i guess. we deal with orders and order items. That means deleting thousands of shipped orders every week to allow the app to focus on the ones being currently processed.
deleting through a relation or api is very costly
You can test it, but I believe if you trigger the “delete through relation” when youre in the builder, it wont cost any updates 
2 Likes
we only delete through the builder to be honest. Its just that with Google Sheets, its very easy to monitor what has been deleted etc… With Glide Tables, my experience is very bad. Incorrect Rows deleted or delete action not fulfilled etc…
in brief, we don’t delete rows during the hours users use the app. its only every morning, we delete 1k - 3k rows with 1 click on google sheet (after backing up)
I am not convinced it is safe to do a 3k row relation delete action on Glide. I’m remember trying it on way lower number and having issues a few months back. might give it a try sometime.