Sheet Edits Quota—1000 per month?

So you hit the reload button 1000 times, or are you doing extensive testing that syncs data to the sheet 1000 times? I think they are trying to keep the monetary costs of syncing data to a minimum. I suppose extensive use of entry components on a detail view screen could up the edits count quickly, compared to a form or add/edit screen that only updates on submit.

I think there is something going on here. So my DEV app browser tab was open. Didn’t make any changes to the sheet or App layout. My edit count went up by 5. My sheet is being edited by the background google apps script though but the screen I was on was pure static home page type screen.

The screen you are on might be static, but I suppose if there is frequent background syncing happening and the data changes often, then that might get ya. Not sure how the background sync is designed to work, but I assume as long as the app is open, then it’s syncing, so the data is always ready when you open that view in the app.

Jeff thanks for explaining. So I didn’t touch anything. The count is now up by 5. @david, could you not sync or increase the sheet edit count when I am not on that browser tab? This is not good. I usually keep the glide tabs open in case I want to work on it. I now get it how I reached 1000 so fast.

1 Like

The edit count increases when your sheet is edited, not when you are merely looking at your app. Can you please make a video and send your app link to so we can investigate? It may be a bug.


I thought you were saying that edits done in the editor would not count against the number of edits.

To me that would be a natural to be able to do all your development in the editor and then have edits done by the users in the app and that will count against the 1000 edits. If you have a lot a users and want to have them input data then you will have to update.

We do not want to count your development activity against your usage limits—it works against all of our interests to limit that. We’re continuing to monitor this, and have already made some changes to improve it.


Glide is great, yes. Glide is one of the numerous players to enable no-coders to transform their idea into reality, yes. Glide as any business/startup has to earn money, yes.

But also, as any StartUp, Glide is partly co-built by its early adopter users: via their feedback, their involvment to on-board new users on this forum, their demo without referral for months etc.

One balanced approach to think about (and applied by several startups) could be to apply new price/limitations to new users, not to the existing ones.

In addition to this, as many here testimonied choosing a no-code solution is an important investment for a user in terms of time, and a risk in case the startup fails; therefore, “Transparency” (as @Krivo) said is key.

@m I follow your channel on Youtube and I agree with you, I will be one more to stop using Glide, because to pay for a Pro value in Brazil is impossible.

1 Like

You got a good point!

I have to admit that the first (and now still the only) Pro package I paid, it was paid with misunderstood that it was a “All Pro apps per year” Before that my thoughts was going back and forth about was it worth it? Could I make a living by making apps? Then I had tried for few days to realise that I could cope with the framework and then I paid, with thoughts ready in my mind about “how many apps should I made per year to handle the subscription fee in total by dividing cost onto each app project” Then I decided to pay for Pro.

But then I knew I got the pricing model so wrong. It’s a one-pro-for-one-app model. Now I had to change my thoughts and stopped thinking about making serious business from every projects out of the service right away. I will only pay for Pro when my apps are desperately needed of rows, or when I could find the clients… Now you made me struggled of trying harder to make a living. And the Casual Sloth mode trial was eating me now instead…

The market position is so related to the business model at this point about how you’d expect your community to be; A lot of people creating casual apps, or a developer-wannabe-from-designer-side-who-think-they-know-the-logics to try on and then start make a living by Glide. Also maybe make the world a little better place one app a time.

From another view, what I thought was a common way to think about paying for a host yearly; A very common way of Developers to consider about the costs. I think Glide in looks pretty much like an SAAP with no database service (You are using a free Google Sheet, which is cool in a way) But you happened to have hosting, which I guess because setting up hosting by users could lead into something pretty messy some time. In conclusion, what I saw is a software service with hosting space service bundled.

This leads to the fact that, when you are trying to value “Sheet Editing” customer (users’) would not relate their thoughts to why should they pay. The Google Sheet is alway free. Reading the sheet might not free, but the service was pretty much part of the job description Glide should be able to do. The rest was “Storage” which I think, if I were you I will try to work that out and see who uses up my storage space and they could be the one to share the costs with you by a right revenue model.

In the end, I think the SAAP part for the interfaces and logics are good to name any price (which you already did in Pro package I guess) And the other part is the Storage where you can name the price. And many more. But please don’t calculate something out of your mandatory way of work. Users could notice way too fast that they don’t deserve it even it sounds fair to Glide. That’s what I think.

cc @david

Yes, you would think that reading a sheet would be free! I would have thought so, too. Unfortunately, it can be expensive–some apps cost us $10-$50 per day because of how often they read their Google Sheet.

We don’t like that this is the case—we think it should be free! Given that it isn’t, what would you suggest? Clearly we cannot just… pretend that it’s free. Glide would not last very long!

We’re working on a new data source that isn’t a Google Sheet, that lives just in Glide, that’s a lot less expensive to update! We may be able to pretend that it’s free :wink: Would you be willing to try that?


Hi David,

I’m glad to! Bring’em on. :smiley:

Apart of all these, as I am working as a UX strategist here. I think there are options you could consider in terms of “reducing the cost—gaining more revenue” with the recent issue about Sheets costs & Free app limitation.

(Well, maybe you’d already considered this but allow me to share my thoughts)

I think:

  1. On the Reducing Costs #1, you can start from making a Reload Sheet button acted as an actual counting switch for Google Sheet update limitation; I don’t think any developers will need an automation until they launch for people to try. This means you can stop the automatically update for not Pro users.
  2. Reducing Costs #2. Since all the data will be shown on “Data” tab after reloaded sheets. Any editing here can just stay here for a while until Reload Sheet has been clicked.

This came from my real use cases that I noticed myself “will only go back to Google Sheet whenever I need to create the formula on column heading” which happens rarely. And since your Data tab works perfectly just like Google Sheet itself, why bother keep on updating that for us?

  1. Gaining Revenue. I still think that using Google Sheet has lots of perks for my customers (well I just have one) on the Usability part since they don’t have to learn anything new. They don’t have to load any specific spreadsheet program/app/interface to work with. Besides, Sheet is recently so powerful, too powerful to reinvent this wheel.

I suggest that. So far if you could reduce the cost of connecting to Google Sheet by #1 and #2, you could try adapting your revenue model to slowly “Charging the Pro users more by Google Sheet connectivity cost” by making this covered your expenses in some ways. As I knew about Firebase/GCloud cost model, they also charged per quota, right?

Tried to make sense out of it. And if there are something more I could help. You had my email in the system :wink:


@Mark, is it normal that 1 sync counts as 5 Edits?

Be great :+1: when glide is able to move away from google sheets as the only source for creating apps, bring it on I say.


The stuff my dreams are made of! :joy:

1 Like

Absolutely :stuck_out_tongue_winking_eye:

That should not happen. Could you please share your app, and maybe make a video of the behavior you’re seeing?

I think the pricing schema for glide is doing great so far since you can build your schema not on a one time and charge a monthly charge. Even lower than other low code platforms and when it comes to customization its powerful

1 Like

Hello @david, I have sent a video & link to my App to support email. Please take a look. My edits are continuously increasing in background (in video you see they were 1324 yesterday around noon - today when I am writing this they are close to 1400). I haven’t made a single change to my App or Sheet during this time.

I already paid 10$ once to unfreeze my dev environment. I am afraid this is really not going well and I am losing confident in my dev environment. It’s like VS code asks you to may 10$ to save your work!

This billing aspect should be put on hold until a reasonable metric is identified.

Thanks again.

@mthakershi I will reset your edits. While your Google Sheet is open in Chrome, it continuously sends data updates to Glide, which is what is being measured here.