Big reference table slowing down app

I have a big table that sometimes needs to be queried as part of the users app experience, ie:

  • when the user views a contact’s profile, it needs to show historical events linked to the profile

previously i added these legacy events into the app as a glide table, and the table slowed down so much i had to remove it. please can you guide me on the best way to implement? (i was thinking creating an external db to reference but perhaps big table or big query might be a better solution? i need to choose whether i stay on pro and do an external table, or, upgrade to business and use big table/big query

any advice appreciated

Big Tables are the way to go, as rows are only downloaded to the client device as they are needed for display.

1 Like

and if my legacy table is created as a big table… would it make sense to archive all old events to the same table - or do you suggest a different alternative for a “growing legacy/archive table”


How big is your GT: 30k, 50k or 120k rows?
How many columns?
How long does it take to respond a query and show the data on your APP?


and my last question @Darren_Murphy , what do you suggest as the next best alternative if my client doesnt have the cashflow to upgrade to $249 per month on business?

about 50k, with 20 columns. the last time it slowed my landing page down to take atleast 10seconds… but i was trying to present a graph on it… perhaps if i limit it to a list on another page other than opening page of the app it will be better?

When you say your legacy table is a “big table”, I assume you mean a very large regular table, as opposed to an actual Glide Big Table, right?

If you are switching to Big Tables, then you should keep all the data that you still need to access via the App in the same table. With Big Tables, there is no difference in performance between 100 rows and 1 million rows.

My suggestion then would be to offload/archive older data to some other place that isn’t referenced by the App.

correct its just really big

what is the best method in your opinion to offload data to another place… do you think i would be able to automate this based on date for example if a record has a date older than 6 months export it to somewhere?


But your problem starts when you try to open the chart by filtering the data or when the APP loads at first?

You’re currently on a Pro Plan, right?
This limits your options because you don’t have access to the queryTables call.

Just off the top of my head, an option might be:

  • Periodically export the whole table as CSV, and store it somewhere.
  • Set up an action somewhere in your App that targets and deletes the oldest row in the table that’s older than 6 months old. This can be done in such a way that it “piggy backs” on one or more other actions. So you’d essentially be crowd-sourcing the job of cleaning out old rows to your users without them being aware of it.

it was both… the app would take very long to get to the home page…and the home page took super long to load with the graph


I think I would use the Darren’s suggestion

that sounds like a great interim plan… thank you