Hello, Glide Community!
I’m facing a serious performance issue with the Glide Editor that has made it almost impossible to work on my app recently.
The Problem:
My main application has over 50 tables converted to Big Tables . When I’m working in the editor (both the Data Editor and the Layout Editor), the interface lags horribly, freezes for several seconds with every action, and often becomes unresponsive.
What I’ve already tested:
-
I created a new, empty application, and the editor works perfectly fast and smoothly there.
-
The performance issue only occurs in my main, large application.
This leads me to believe that the root of the problem is the number of Big Tables or the overall volume of data and relations within the app.
My main question is:
Is there an official or community-known limit on the number of Big Tables in a single app that could drastically affect the performance of the editor specifically (not the published app itself)?
Has anyone else encountered a similar situation? Are there any best practices or workarounds to optimize an app with a large number of tables?
Thank you in advance for any help or advice
1 Like
The usual suggestion here is optimizing your data structure and your computed columns. I haven’t personally had an app wiht that many Big Tables, maybe you can consider whether all 50+ Big Tables are necessary. Sometimes, consolidating tables or archiving old data can reduce complexity and improve performance.
Use the Performance Mode button here.
So you can know which columns are taking the most time to compute, and optimize them if possible.
Remove any relations, lookups, or computed columns that are no longer in use. These can accumulate over time and slow down the editor, even if they aren’t actively used in your app.
Thank you so much for your suggestions! I really appreciate you taking the time to help.
I want to provide some more context as to why the standard optimization methods don’t seem to apply in my specific case:
-
Column Optimization: I’ve been using the “Performance Mode” feature extensively. The results are clear: the bottleneck isn’t here. My most complex and “heaviest” column takes only 9ms to compute. This confirms the performance issue is not happening at the individual column level.
-
Data Structure & Legacy Data: This is a brand-new application, built from the ground up. There is no “cruft” like unused columns or old tables that could be archived. All 50+ tables are part of a normalized data structure and are essential for the app to function. Consolidating them would introduce data redundancy and unnecessarily complicate the logic.
This brings me back to my original hypothesis. The problem doesn’t seem to be the content of the tables (i.e., slow columns), but rather the sheer volume of tables and the complexity of their inter-relationships . It feels like the Glide Editor itself is struggling to load and manage the metadata for such a large-scale application.
So, my refined question for the community is:
Has anyone else experienced this specific scenario where the Editor’s performance degrades significantly due to the architectural scale of an app (a high number of tables), even when all individual components are optimized? Is there an unofficial “soft limit” or tipping point for the number of tables where the editor’s usability starts to decline?
Thanks again for any insights.
3 Likes
Interesting post. Sorry I haven’t got any suggestions other than what you have already tried.
But I will keep an eye on this thread.
I do wonder whether native glide tables would perform better? (Assuming you can stay within the glide tables row limit)
