Help needed - My solution with 10K users, consuming 5K updates per day

Dear Fellow Glide Experts,

Urgent help needed here. I just launch a pilot program with 10K users in plan (currently 500). I found that my updates are consuming too fast. First day of launching have consumes 5K updates for 500 users (i’d think this is reasonable as users are updating their profile, adding personal details and take pictures.). However, I found that my updates consumed too fast because I am using QuickChart to plot a graph to show the incremental of users in my app. Each user might query this charts multiple times to see the latest usage for FUN, but this will consume my updates. Of course i can turn this features off, but what is the points to use Glide if I cant even perform simple query?

How are you calling quick chart? Just use template column

Yes, I am using template col. Also it is more complex which I am using Javascript to query information from other glide table, and then construct a HTML2PDD with Replit so that my chart can be placed into a PDF as final report.

Updates are sometimes a little overlooked. I think it’s worth scoping number of rows, users and updates to see how these will affect pricing but also features of the app.

Let’s take the Maker plan as an example. Unlimited users, 500 monthly updates. That’s roughly 15-20 daily updates across the app for unlimited users. That’s around 1 daily update with 20 users. That’s 0.1 daily updates or 1 update every 10 days if there are 200 users. And so on.

Note that on each plan, additional updates cost $0.02.

In general, as a general rule of thumb, if you want to limit costs related to updates, use Glide Tables and avoid 3rd-party integrations that would otherwise incur syncs.

I found that this Drop Down selection is consuming update. Whenever user pick different choice, it will write to glide table and count as 1 update, however, i need this value to perform query for my chart. Is there any workaround?

image

Thank you, Nathan. I am using Glide Tables. Understand that in pilot launch, it could be consuming more updates, and it could be lesser when in normal run time. However, I need to use integration for image compression, else my glide table might be exceeding storage limit with 2MB image per capture.

I just found out that I have used Form element - Choice a lot for user to query different date from tables. Every change value of this cost 1 update. How can I workaround this?

What plan are you using? You will see this in the Glide dashboard just below the name of the team where you app lives in the panel on the left-hand side.

If you do this in a team that you created recently with any of the following plans – Free, Maker, Team, Business – then normally writing to a Glide Table via a choice component should not incur an update.

If you are on a legacy plan, then updates are counted differently:

Updates on Legacy Free Plans

The following consumes updates on the legacy free plan. Note that data changes consume updates per row changed. Changes to Glide Tables and Big Tables are counted.

  • adding, editing, and deleting data
  • syncing external data
  • actions and computed columns from integrations

If your team hits the quota of updates allotted to your plan, you can enable Unlimited Usage to keep using updates during that billing period. Depending on which legacy plan you have, updates will be charged to your account in one of two ways:

  1. $0.01 per update used over your quota
  2. $10 per 1,000 updates used over your quota

The unlimited usage modal on the billing and usage pages will indicate which unlimited updates billing structure your team is on.

3 Likes

Hi, Nathan,

Just found out that I am legacy start plan now… thank you for your help. Will upgrade my plan accordingly. :slightly_smiling_face:

1 Like

Before you do so, have a close look at the difference between the Legacy Starter plan and the Maker-Team-Business plans.

Once you stop your subscription to your Starter plan, you won’t be able to get it back.

You could also try one of the others for a few days or weeks to see what works best for your use case.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.