500 Row Limit - What Counts?

Now thats a reply.

1 Like

Sorry to go off topic, but do all formulas in Google sheets cause a delay, or only ones like this Vlookup? I ask because I put a column into my Google sheet that’s simply a lowercase conversion formula, and ever since then my app takes five full seconds to load instead of the immediate load it had before. (I have a relation within Glide to this lowercase column too) I had made several changes at once in addition to this one before the delay occurred so I’ve been avoiding the nightmare of trying to track down the culprit! Are formulas a main suspect?

The delay is in Glide really, so when you send/enter new data it just has a delay to refresh its data,you would see the data in your sheets within seconds, the formula is instant its just how long glide looks back at the data again. Glide says they refresh the data every minute or upon data being edited. The problem with this is a fornula result changing isn’t considered a sheet edit, it’s considered a sheet change. And Glide only updates on a sheet edit and every minute. With that being said, when google sheets are closed and you are using formulas for returned values it actually takes about a 3rd of the time.

1 Like

So there is one way around this, I’m sure they don’t want us doing this but you can write a script (I actually have here on the site) that works with onChange edits and creates a edited event that Glide immediately sees and refreshes your app, this brings it down to 4 to 7 seconds. Again, I am sure I will be told to not tell people about this because I think Glide says it costs them a per edit cost, now I am unsure of that. I’ve tried to find the google sheets api pricing but all I can find is this article from google regarding their sheets api pricing where they say it’s free.(Pricing  |  Google Docs API  |  Google Developers). But maybe the cost is on Glide’s end with data processing and data retrieval. I am unsure but there you go.

1 Like

This isn’t true. The Google Drive API notifies us of sheet changes at most every three minutes.

I also think this is not true, but go ahead if it works! It will count against your sheet reload quota so you could run out of reloads.


Like I said it is probably frowned upon, but if you have PRO or more your sheet loads are unlimited. I did do a test on this @David a few months back and put the results somewhere in the forums I spent 3 days attempting to speed up the process which led me to this result. I don’t know where it is but it was a week long forum conversation I believe. I was trying to have instantaneous information fed to the app before we had Glide sheets as an option.

Here’s the posting, in this post I had it down to a consistent 1 minute for a few days. Shortly after posting that finding it went right back up to 3:45. Then I implemented the most recent mention that forces the edit.

Glide should be pretty good about dealing with emails in a variety of character cases. I know Glide has worked on a few bugs regarding emails and mixed character case. Are all of your email columns marked as email columns? What is the reason for doing the lowercase conversion? If email case is a concern for you, I would consider creating a Unique ID to go along with that email or user. Then use that unique ID for all of your relations. However, if you are relying on the use of Row Owners, then you still need to use the email, but in most cases, the letter case shouldn’t make much of a difference for emails, unless you are running into a particular issue that you could explain.


@Jeff_Hager I have an email column marked as row owner in my User Data sheet. This is the email address the user logged in with. Also in the User Data sheet I have an email relation column which connects User Data to the member directory sheet where members have input their own email address, sometimes using mixed case. I then have a look-up column which specifically looks up the email address that the member input into the member directory sheet. All of this is so the app knows when a logged in user is a directory member or not. I discovered an issue as soon as I shared the app with a few test users where Glide does not match mixed case email addresses in the lookup column - meaning a member who used a capital “D” in her address was not being recognized as a member. I fixed this issue by creating a hidden column in my directory sheet with a formula that converts all emails to lowercase. I then changed my Glide sheet to reference that column instead. I did some research on the forums and it seemed that Glide’s relations are case-sensitive? I am guessing that columns marked as “email address” are not, but there is no way to mark a look-up column as “email address” - right? Is there a better solution?

(I don’t want to ask my users to modify their behavior - my gut says that is never the solution)

Hi Amanda,

Are you using an email picker to collect the emails? I believe that would help you with your problem.

Is an email picker something within Glide or something within Google Sheets?


@SantiagoPerez @Rosewebstudio the profiles within my app are using the email entry component to display and edit email addresses. The initial entry of the email address happens on the shared Google sheet.

I would probably have a second column in your google sheet that takes the original entry and uses an arrayformula to lowercase the email. You could probably hide that column from view so the other members don’t mess with it. Relations are case sensitive, but doing it this way will give you the second lowercase column to use for the relation.


@Jeff_Hager that is exactly how I set it up :sunglasses:



Where can I confirm my row count with the free plan ?
By the way, where can I buy the $5/month boost to increase the number of data rows ?

Thanks a lot,

In the builder, hover over the link at the top right that shows your plan type, and it’ll show how many rows you have used.

Paid boosts are no longer available. If you want more rows, you need to upgrade to a paid plan.

Hi all - new to Glide and excited to build out an internal app for our field service workers to create/update work orders that fit with how we use Airtable to manage our operations.

I’m trying to better understand best practices to reduce the number of rows and updates that Glide counts for in our app.


To start, if we sync a table from Airtable, what can we do to filter/prevent Glide from counting rows that we don’t need in the app?

If we filter out rows in Glide, does this make them stop counting?

Is there a way to sync a specific Table View from Airtable that has already pre-filtered the unneeded rows so they don’t count?

If we have our technicians update 20+ fields in a given work order, would this count as 20 updates? Or would this count as one update once they publish?

Thank you!

1 Like

@Matt_Cleen we only count rows used in your app, and you can remove unused Airtable tables.

If your work orders are created via a form, or edited via an edit screen, where the 20 entries are edited before being submitted, that is just one update.