Handling concurrent users for calculator apps

I am currently working on building a financial calculator app and my use case is similar to these in terms of data structure and layout -

There are google sheets with just 1 row where user input is collected and then the outputs are captured in the same row based on calculations. These calculations involve a few other sheets in the background where the input is taken and output is generated.

I realized that since the backend data is simply 1 row, is it right to assume that these apps cannot handle concurrent users? Because, as soon as 1 user enters a value in the sheet, any other user using the app at that moment will start seeing the input values in their app as there is just 1 common database.

One option is to create user inputs per user but that causes issues while sending inputs to the calculations as they can accept only 1 input at a time. It cannot handle multiple inputs from different users at the same instance.

The calculations are complex so doing the calculations per user will obviously slow down the app.

Any thoughts or recommendation on how to allow concurrent users to use these kind of apps?


1 Like

Yes, that assumption is correct. To properly handle concurrent users you should be collecting your input in User Specific Columns, and performing all calculations in Glide.

See below for some inspiration:


Thank you for your response.

The calculations I am performing are slightly complex.

For example - this is a returns calculator, it takes the inputs (highlighted cells) and outputs the returns

This uses a bigger calculation table which has 100s of rows which calculates the returns per month for the whole period.

Any recommendation on how best to structure this to make it User Specific? One thing I worry about is doing the calculations per user will make the app very slow given the size of calculations.

This still sounds doable. I like to use what I call work tables, which are pre-populated tables, but have some values that can be entered or passed in from user input which determines how the rest of the table will calculate a result. So, one of your tables could hold your user inputs in user specific columns, and then you pull those user specific values into your working table, where all of the other calculations can be performed.

Building all of this in glide and making it work, using user specific columns, for multiple users to use it, would be absolutely night and day as far as performance and speed. Right now, if you are relying on the Google sheet to handle all of the calculations, then you have a cringeworthy delay waiting for those results to come back. Plus you are most likely stuck with one user using the app at a time. When you move everything into glide, then your calculations are working as fast as you can type. Like the calculator app @Darren_Murphy shared, it’s performing those calculations instantly as you are typing numbers. None of it uses a google sheet, so it’s all real time. And at the same time, since I use user specific columns to store values, hundreds of thousands of users could be using my calculator at the same time and nobody would be interfering with anybody else.


@Jeff_Hager Yes, I am struggling with the Gsheets and want to migrate it over to Glide tables.

Quoting your comment “pull those user-specific values into your working table, where all of the other calculations can be performed.”
can you share how best to do this? I can create user-specific columns but wondering how i can pass user-specific inputs to the common working table because the working table can only handle 1 input at a time? Or am i wrong here?
Do you have any examples where I can see this being implemented?

As long as you made those columns user-specific, it will only handle the input of the signed-in user, so that they don’t override each other.

1 Like

Yes, as @ThinhDinh pointed out, as long as the computed columns use user specific columns in their calculations, then the result will also be user specific. This is something you just can’t do in a google sheet, but can in glide.

You can use Single Value columns or Relation/Lookup columns to bring data into a working table.

Again, my calculator app linked above is probably the best example I have. The math occurs in one row, but the user input is through user specific columns, so each user’s experience is unique to them. Even the calculation history table is user specific. Only 20 rows of history, but what each user actually sees is their own history and not anyone else’s.

It’s important to know that computations/calculations in glide happen directly on the user’s device. Not on the server. As a result, those calculations use whatever they “see” for data. If the data is user specific, then those calculations are based on that particular user’s specific data. Each user has a separate copy of the database that is synchronized between their device and Glide…and from Glide to Google. It’s not like a google sheet where everybody works with one copy, and all calculations are happening in that one copy. When you use user specific columns in glide, the experience can be quite different from user to user. It’s all about thinking a little differently from what you are used to with Google sheets.


Thank you for the detailed explanation, it makes sense to me now.

Create the input cells as User-specific and use another generic table, but we have to do this with Glide Tables to make it work. It wont work with Google sheets.

1 Like


While the generic table would probably make more sense as a glide table, it can still be a google sheet, but all you would have on the google sheet side is probably a single column with some random data, or maybe some sort of a number that would help to determine your calculations on each row. At that point, it would just be easier to use a glide table instead. All of the rest of the logic would be within glide, using glide computed columns, regardless if it was part of a glide table or a google sheet.

1 Like

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