Big Table Limits

Are there any good resources explaining clearly how big tables work & are priced & are loaded?

There are some questions that seem to be a bit confusing:

  • How are big tables loaded (row count, starting from top or bottom etc…)
  • Are we allowed 10 million rows all big tables combined or per big table
  • Do big tables reduce the performance/speed of an app on a user device lets say an app is connected to 5 big tables each are 1 million rows.
  • What is the best way to backup big tables once we reach the 10 million mark ? is the data downloadable or is there any good advice where to take it?
  • Do users put big table data in charts, what is the price of doing so, what are the limitations of doing so …etc.

Appreciate any input on Big Tables here.

and i thought big table was THE data source Glide supported the most …

I’m curious, what makes you think this? Without any limitations on computations, I would have thought normal Glide Tables would be that one.

Wasn’t it mentioned somewhere here that big table are the future of glide tables

It might actually be, but at the moment the statement that Glide supports Big Table the most is not correct in my opinion.

Yes obviously its not correct … as you can see it has been hard to get any answers to some simple big table questions.

Even the ‘reload query’. Seems hard to know how many updates that would incur if added to an action.

1 Like

Yeah, I’m just as curious as you. Maybe @Darren_Murphy has more experience than any other in this regard.

1 Like

Just based on observation, the first 1000 rows are loaded, and then other rows are loaded as required.

My understanding is that 10 million rows is a “marketing” limit. In practice, you can have as many rows as you want.

I’ve not tried it, but I would expect that CSV export will work no matter how many rows there are.

A chart is just a different type of collection, so the same limitations apply around computed column types. Other than that, Big Tables work fine as the source of a chart.

Each reload is one update.


Thank you so much @Darren_Murphy

We are in the process of putting Order history data into Big Tables.

That would mean 3 big tables

  • Orders
  • Items (OrderID included)
  • Bookings (ItemID included)

Its a bit challenging to understand the costs involved and the best design taking into consideration that user device performance is very very important for us as its our major problem using Glide for our operations team.