I started this little adventure in 2022 when google tables were the norm and Glide tables were becoming a ‘thing’. In the nearly 4 years later Glide table support has grown by…checking notes…..ZERO. 25,000 google sheet rows then….25,000 Glide table rows now.
At first I thought 25,000 was the limit per table when about 6 months into this venture I discover it was ALL rows in the App. Yikes. But the app dev team was moving forward swiftly so what could go wrong.
Fast forward 4 years and a Glide app based on a Glide table is still limited 25,000. How is that ‘Enterprise’? The original Glide ‘mantra’ “Put the power, beauty, and magic of software development into the hands of a billion new creators” didn’t mean 1B creators learning SQL integration?
If it was the hardware-related then why can’t Glide use/require bigger/more advanced hardware like an LLM does?
I am still baffled about these limits and if there is a roadmap on databases in Glide.
Is there any technical reason why a Glide app can not support 500,000 Glide Table rows within a single App with the the proper hardware sizing?
Of course…but Big tables have limitations when it comes to querying and calculated columns.
And moving from a Glide table, especially a complex Glide table that is used a lot in App, to a GLide BIG Table is a direct re-write of all screens and logic.
Again….the question is why are Glide tables STILL limited to 25,000 for an entire app.
Because Glide tables running on user device locally after downloaded and most of device can’t handle more than 25000 without dramatically degradated performance.
Maybe in 2021…..but not 2026. The phones are literally 2x or more (CPU, internal memory and app storage) bigger, faster…
Given the new ‘UI/AI’ functionality in Glide, I believe its data architecture should be able to scale with improved performance of the underlying hardware.
Yes moving from normal glide table to big table is a big hassle. Please vote on this feature request to hopefully get more attention from the glide team on this one.
If Glide had now given us the opportunity to add an SQL server to the application, not as an external data source, but as an internal one (to save on extra data accesses), with the ability to configure this server, this would have resolved most of the issues related to the restrictions on query and rollups in GBT.
With the development of modern AI, setting up a server is not difficult, but it all comes down to the cost of updates.
I feel the same at times and wonder why the limitations haven’t changed all that much in years.
I think it depends on the lense you use to look at this.
So many of us are using Glide to build full-blown apps with a bunch of features for a bunch of users, at times replacing a SaaS solution. It’s fun, satisfying, and sometimes that’s what we’re being asked to build. But sometimes I think we’re building these solution because we can with Glide, not because we should.
I recall the original ethos of Glide: build an app on top of a Google Sheets spreadsheet. If every user of Excel and Google Sheets built a quick Glide app instead of a quick Excel spreadsheet, then indeed Glide would have put the power of Glide in the hands of a billion creators. And the world would be “graced” with simple Glide apps instead of those nasty spreadsheets. The needle in Glide’s foot here is that no matter how easy Glide has made it to build apps, it’s still more straightforward (quick and easy) to throw together a spreadsheet than an app. It seems it’s a hard problem to solve.
In this latter scenario, two points are clear:
We could be building one app for one use case instead of monster apps. Just like most people build simple spreadsheets and not monster spreadsheets.
Most spreadsheets use way less than 25K. I don’t have the data, but I would guess this to be the case.
A long-winded answer to say that based on Glide’s original ethos (if I interpreted it correctly), we don’t really need all that many rows. Though I understand why many of us ask for them, myself included.
Yes we’ve managed to drive many round pegs into square holes using Glide, I wonder if the CEO or others in leadership at Glide ever intended for the app builder and apps to be used the ways they are currently being used! ALSO I wonder the future of Glide, can we still bet on it to have the lights on in 5 years? 10 Years? Everything changes so quickly, and i’ve built up quite a bit of infrastructure around Glide, but am always nervous.
To talk to the converting to big tables issue.. I had a monster glide table with over 200 columns of data, with UI hooks everywhere, computed columns galore etc. it took me one full day of no interruptions and a heavy amount of brain RAM being used, but I did manage to get it transitioned over, there is a “loose” guide on here on how to do it properly which helped me align myself. Lots of the issues with computed columns I was able to solve on the back end with how data was being pushed into the app anyway, did glide NEED to be the one computing it? No, I have make.com do all the heavy lifting now, glide is really just my user interface.
Trust me, Glide Team is aware of the opportunities and challenges of our era. They are working hard to stay ahead of the game. This year and next year we can expect some really exciting updates that will enhance both performance and functionality of Glide apps.
Sure, these days we don’t know what the world’s gonna look like in a couple years, but I prefer to stay realistically optimistic .
.