App extremely slow / not loading after creating multiple query columns for dashboard

Hi Glide team,

I’m building an internal dashboard in Glide to track key metrics for my cleaning business. Unfortunately, the built-in charts are quite limited — they only display basic visuals without interactive filtering — so I decided to create many query columns in the Data section (since I couldn’t find another way to retrieve filtered results).

Each query pulls specific metrics (like services completed, hours worked, clients acquired, etc.) across different categories and date ranges. For example, I need to see how many services were done in a certain city (e.g. Montreal), during a specific date range (e.g. June 1–30), and divided by service type (1. Regular Cleaning, 2. Deep Cleaning, 3. Airbnb). Since Glide doesn’t offer that natively in the charts, I’ve had to build it manually with queries and display the results as text.

But ever since I implemented this setup, my entire team has been experiencing serious performance issues. The app now takes a long time to load (sometimes failing entirely with a timeout error). Buttons can take up to a minute to respond, and this is happening across all ~80 users — not just a few.

To produce a simple breakdown like the one below:

I had to build about 12 query columns plus 12 rollup columns, and similar structures exist across multiple tabs. Here’s an example of what the data logic looks like:

I’m fairly convinced that the high number of queries and rollups is what’s slowing down the app, since this all started happening after I added them.

So my main question is:

→ Can having too many query columns significantly impact app performance in Glide? And if so, what’s the best way to build a dynamic, filterable dashboard without compromising speed?

To be clear, I’m not trying to do anything overly complex — just replicate this type of view from Google Sheets:

But I can’t get even basic segmented metrics (like sales by city or bonuses by type) without dozens of backend queries and rollups. Without filtering options in the default layout charts, it’s extremely limiting — and the workaround is killing performance. To be clear, i know that some charts have date range filters, but it only applies to the chart, all the text info will rest unfiltered, which make it useless.

I’ve moved my entire business over to Glide and I really want to make it work, but so far, it’s becoming more difficult and slower to use than what I had in Google Sheets :disappointed_face:

If any experts offer 1-on-1 consultations (even paid), I’m open to that. I’d really appreciate any guidance or solution — I need to fix this urgently.

Thanks so much in advance!

1 Like

For starters, I would drive your screen with a single row helper table. It’s hard to tell what you have going on, but it seems like your are allowing queries to run on multiple rows. Queries are heavy in the first place but if you are unnecessarily running them over and over on thousands of rows, that’s going to have an exponential effect. I would hope you could have the same queries in a single row table and get the same results with a lot less overhead.

Another thought is to maybe use Single Value columns in your large table to bring in your filter values. Then use them with IF columns or filtering to control what’s displayed on the screen.

If those ideas don’t help, then I think we need a better idea of how you have this set up. What table drives the screen, what table or tables contain the data you want to view, how are your filters set up, etc.

5 Likes

Hi @Jeff_Hager

Do you offer 1 on 1 consultations, i think it would be easier to connect and show you everything in a call

Thank you!

1 Like

No I do not. Forum only.

1 Like

Okay, so if I’m following you correctly, you’re suggesting that instead of placing the query columns in my Cuentas table (which is my largest table), I should move those queries into a separate table with only one row — that way the query only runs once, rather than being evaluated across hundreds or thousands of rows. Is that correct?

That actually makes a lot of sense and could explain why things have gotten so slow — especially since I currently have those queries running directly on my main data tables.

Regarding your second suggestion:

“Use Single Value columns in your large table to bring in your filter values. Then use them with IF columns or filtering to control what’s displayed on the screen.”

Just to clarify — in this setup, where would those filter values come from?
Would they still be generated from the query results, or would they come from something else ?

I’m just trying to fully grasp how the flow would work:

Thanks again for taking the time to help @Jeff_Hager — I really appreciate it!

2 Likes

That’s correct.

I think he means getting them from wherever you’re storing the filter values that the user can interact with.

4 Likes

Okay, I think I get it now — and honestly, I feel like I could optimize a lot of my queries with this approach :joy:

I’ll try restructuring things as you suggested and monitor the app performance over the next couple of days. If I still run into issues, I’ll definitely follow up here with more details on my setup.

By the way — @ThinhDinh do you offer 1-on-1 consultations? I’d be happy to pay for a session to get expert help if needed.

Thanks again for your support, it really means a lot!

2 Likes

Sorry I don’t, just forum for me.

1 Like

No worries — I’ll follow your advice and get back to you if I need any more help.

Thank you two so much again for your time and guidance! :folded_hands:

3 Likes