Both. Soā¦ i understand. Thanks
1 Like
Hereās another question for the team.
Currently, you cannot purchase additional Public Users or Private Users. If you need more than 15 Private Users, you will need to upgrade to the Pro team plan
2 Likes
I have a question in regards to plan Rows per Project and Updatesā¦
In the PRO plan, the pricing page states that you can have 25,000 rows within that plan. It also states that you can only have 10,000 Updates within that tier.
Based upon the wording of updates, an update occurs when a row is added. So how can you ADD 25,000 rows when you are capped at 10,000 updates? Do you have to purchase an additional 10,000 row updates (for an extra $100) to hit the row capacity within that price tier?
See my highlights in YELLOW
Hey, Steven!
Adds only happen when you add rows to your data source from your Glide project.
If you add 25,000 rows to an external data source (like Google Sheets) or our native data source (Glide Tables), Syncs will happen, which can be as low as 1 Sync for the 25,000 rows depending on how quickly you add them
2 Likes
Hi there, i would like to know if the Updates Limits are currently being enforced. And also if we can Migrate a specific app from Pro Plan to Business Plan and then to enterprise as we grow.
Hi @ToOFa_Apps
From what I understood from prior interaction with @DJP, the plans are on soft lock for now, that means your account wonāt be locked when you exceed your quota but of course there is a limit that may result in Glide getting in touch with you if you exceed your quota significantly.
You can also seamlessly upgrade from 1 plan to another from Pro to Business to Enterprise and you will get a notification to upgrade your plan as soon as you are nearing your quota limit.
Perfect. Thanks for the reply.
| | ToOFa Apps - Chat @ Spike |
|
- | - | - | - |
| Luther Regular
May 20 |
- | - |
Hi @ToOFa_Apps
From what I understood from prior interaction with @DJP, the plans are on soft lock for now, that means your account wonāt be locked when you exceed your quota but of course there is a limit that may result in Glide getting in touch with you if you exceed your quota significantly.
You can also seamlessly upgrade from 1 plan to another from Pro to Business to Enterprise and you will get a notification to upgrade your plan as soon as you are nearing your quota limit.
Visit Topic or reply to this email to respond.
In Reply To
| ToOFa_Apps
May 20 |
- | - |
Hi there, i would like to know if the Updates Limits are currently being enforced. And also if we can Migrate a specific app from Pro Plan to Business Plan and then to enterprise as we grow.
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
This is one of the problems with the āupdatesā pricing model.
The distinction between syncs and updates is unclear. The same change to your records could result in 1 sync, 25,000 updates, or somewhere in between. Thatās a huge range, and something we as users only have partial control over. We only find out the true number of updates weāll use after building an app and testing it (which could take hundreds of hours).
Weāre also using tools that donāt have these same update limits (e.g. Google Sheets, Airtable and Excel). Itās hard to wrap our minds around a limitation that makes no sense to us (we donāt see Glideās internal cost structure that justifies linking price to updates) and that we can only partially control. The thought is, if a company like Airtable doesnāt need to charge for updates, why would Glide? Again, keep in mind that most users havenāt run a business like Glide, and donāt have intimate knowledge of the costs involved in updating databases. This means that we also need to consider the update limitations in Glide when building our external systems (e.g. in Google Sheets or Airtable). But many of those systems will already be built before coming to Glide, meaning Glide may not be an option.
We are now required to think about designing systems that would involve fewer updates, which means complicating the design process and limiting what we can build. The worst part is that itās clear as mud how many updates an app is likely to consume before you build it. Thatās like starting to build a car without knowing for certain if youāll be able to afford the gas to drive it. Itās a deterrent to building.
Iām not telling Glide it should change its pricing plans, but simply stating how they feel to this user. They seem arbitrary, limiting, and are a bit frustrating to work with. They require an app builder (or decision maker approving the use of Glide) to think harder and longer BEFORE building an app. This is the biggest concern for me in terms of Glideās longevity. I expect it will be a barrier to entry to the Glide platform. I hope that Iām wrong about that as I really like this platform.
8 Likes
I totally agree, quotas are extremely low, and from my experience do not reflect the actual cost, I understand that Glide needs to make money, but creating apps so limited in operation will not go wellā¦ ie: Google gives 500,000 updates a day for just $12/monthā¦ Glide offers 2,500 a month for $25/monthā¦ I know Glide is not a Googleā¦ but this is gigantic deference
Itās expected that you wonāt add those 25.000 rows within a month, which is the duration of the updates quota. So you will have 10k updates every month and probably you will hit your row limit somewhere in the future
who expects that? when you working on an Appā¦ you will add a database to test, as soon as possibleā¦ not in a month
Thatās why:
- The limits are not being impossed yet
- Updates during development arenāt going to be considered, as told by @DJP
To be clear, if you were to add 25,000 rows to your data source, it will not be 1 - 25,000 Syncs
If you add these rows at once, itāll be close to 1 Sync (i.e., not something you need to worry about)
On your broader point about predicting the number of Updates youāll need, we agree that there will be an adjustment period, but keep the following in mind:
-
We will be announcing soon how Updates will be counted when we move to full enforcement (There will be some changes the community will appreciate!)
-
We chose our Updates quotas based on our customersā usage patterns. The vast majority of Glide users will be able to build without having to purchase additional Updates until their projects start scaling
-
Itās hard to estimate the number of Updates your use case might need now, but as the community becomes more comfortable with Updates, itāll be easier to predict
But itās not just adding rows that count as an update. Making changes to an existing row also counts.
Say for example that I have 25,000 rows in a table and I decide that I want a new column to improve the functionality of my app. I want to include a formula field that displays an emoji to specify the status of each record (
for incomplete and 
for complete). By adding this new field and basic functionality, Iāve now āupdatedā 25,000 rows, as each row will be updated to include one of the two emojis. There may be ways around this, and just scrolling through this thread you can see that Glide is still working on creating various exceptions to what does and doesnāt count as an update, but this is the way it reads when you look at the Glide pricing page. Glide can add a number of exceptions, like not counting updates as part of development, etc., but this just adds additional uncertainty for users. What is considered development? Does it include any changes I make to my app structure? Only changes made while the app is in draft? It may even be that this type of change would only count as one sync. But how in the world are new users supposed to understand all of these nuances? Iām still confused, and Iāve read all 415 comments on this postā¦
When I use other platforms (such as Airtable), this is not a consideration. I donāt need to consider this restraint (which to me as a user seems very arbitrary) when building my app, sheet or table.
In other words, I canāt easily improve my app without thinking through how many updates it will cause, and whether I need to pay an additional fee just to make a minor change to the functionality of my app.
Again, I understand that these changes cost Glide money, and I have no way of knowing what these actual costs are. The problem is that these updates count in some circumstances and not others, and seem to very much limit what can be built with Glide. One of the main benefits of Glide and what appears to draw people in is its simplicity. You can make beautiful apps, without having to be a coding expert. This updates-based pricing makes things much more complicated in my opinion when it comes to end users trying to determine whether they can build with Glide, and how much it will cost. That seems to be the opposite of Glideās approach to date.
For this to work without a negative impact on attracting new users, I think that Glide would need to do a much better job at explaining the reasoning behind the update limits and how updates are actually counted. If you have to introduce 10 different exceptions to make it work, youāve just reduced the likelihood of a new user bothering to start with Glide. If they canāt understand how much they will have to pay without going deep into the weeds of how updates and syncs will apply once theyāve completed their build, youāve just made it much less likely that a general user will commit to even taking Glide for a spin.
Iām glad to hear that Glide is working towards making this more clear. Iām just not sure how you will do that with all of these nuances. Some of the confusion may be coming from the fact that syncs and updates are very different, yet they are both counted as āupdatesā on the pricing page. It doesnāt make sense to me that they would be included in the same quota. A sync that could change 25,000 records could cost me only 1 āupdateā. But if I make the same change in a different way, by updating the records individually, Iāve now completed 25,000 āupdatesā. From an end-user perspective, Iām doing the same thing, but the cost is drastically different. Thatās confusing.
I suspect that it will still be hard to predict for new users, which is one of my main concerns. Simple and straightforward pricing is key if you want to make it simple for new users to understand the cost of your service. Although itās WAY easier to build with Glide than to create something from scratch, it still takes a considerable investment of time and money to adopt a new platform for any business. If you canāt tell from the pricing page how much it will actually cost to build with Glide and whether your use case is suitable for the platform, thatās a major problem.
I look forward to seeing what you come up with and hope that it will be much easier to predict the ultimate number of updates an app will consume before starting with a build.
If you add a formula in your sheet in a new column, all those rows will be updated in the sheet at the same time. They will be sent to glide as 1 sync and 1 update. Not 25,000. Now if you manually added an emoji to each and every row and waited 1 minute between row updates, then yes, there is a higher chance that you could use many more updates. But with your example above, it would really only be a couple of updates at most.
They are trying to differentiate those users that run large profitable businesses and get away with paying pennies, compared to those that have a small use case with a small amount of users and data.
1 Like
If you use an If Then Else column in Glide, this will use zero updates. If you use ARRAYFORMULA in a Google Sheet, that would cause one sync (total, not per row).
Edits happen when you change the data stored in the row. Calculated columns donāt change the data stored in the row.
1 Like
@Jeff_Hager I donāt think so, $25/month for 2500 updates per month is not going after big usersā¦ that is pure profit chasing 