Excel / Airtable as data sources. Pros/Cons?

Excel and Airtable are great additions to Glide. But, what exactly do we gain by this?
I know Excel is much more robust that Google Sheets, but why does that matter? Glide is the weak link anyway, with its soft-limit of 25K rows.
My thoughts are the we can benefit for the combination of Glide table, Google Sheet and Excel (and/or Airtable).
But even here, what exactly to we gain?
Excel has great formulas, and VBA isn’t too bad, but I seem to recall many discussions here saying that it’s best to avoid using formulas in Google Sheets. I would assume the same logic applies to any other data source, no?

I understand there’s a hard limit of 10 rows on the free versions of Glide, but let’s assume we’re talking about any one of the paid versions.

I might come out too harsh in this post and I apologize for that. This 25K rows soft-limit is driving me insane. It’s like driving a supercar that’s limited to 10km/h.


Having access to more data sources allows for more opportunities to get people using Glide. Some are much more comfortable with Excel or already have their data in Airtable. By providing more connections they are reducing friction. I began using Glide because I was already comfortable with Google Sheets. Now I tend to use Glide Tables whenever I can because it has won me over big time. But I would never have even tried Glide if it wasn’t for the ability to use Google Sheets at the start.

While every app is different I’ve found that 25K is by far enough to store all the content needed. While every situation is different Glide may not want to focus on use cases that require more data.

Though in future if you, and others do find that the limit needs to be raised, I’m sure Glide would take this into consideration.


Thanks for your answer and I see your point.

As far as I know, Excel can support ~17 Billion cells and even Google Sheets can now hold 10 Million. These aren’t heavy-duty database tables, but their developers still deemed it worthy to set the limit (hard or not) to be quite high. High enough for most user to, as you say, have far enough room to work.
I’m quite surprised that Glide’s new pricing structure doesn’t allow clear and guaranteed upgrades to the number of rows. Not just relying on the fact it’s a soft limit. It has to be a hard commitment that the Glide engine can support at least hundreds of thousands of rows. Again, this is something you can monetize quite easily as it has a clear value to the user.

I have to be honest. I’m still surprised each time my cry for help on this 25K is somewhat downgraded to a low-priority feature request.

The 25k row limit is a technical limit, constrained by the RAM on your phone. We’re working on it–it’s not an arbitrary business limit, for example.

Glide Tables will always be the best performing, most scalable, most powerful choice. No external data source when added to Glide will give you extra scale or performance.


So it’s not so much an issue for Glide Pages, then? I don’t know that I’ve ever seen that distinction discussed.

It can. At least one million rows, one hundred thousand columns, and ten million cells.

As David said, they are working on it. But it’s not as simple as flicking a switch. “Oh, let’s change the limit to 50k this week”. It doesn’t work like that. As I understand it, supporting 100k rows and upwards requires some fairly significant changes to the way Glide works. And that doesn’t happen overnight. I want this as much as anybody else - I have at least two apps that have already blown through the 25k “limit” and are as slow as… but I know that me jumping up and down about it and making a big song and dance won’t make it happen any sooner.

1 Like

Thanks for stepping in and clarifying this.
If we assume (or even instruct/advise) that users work mainly from desktops, can we assume this limit isn’t relevant? Is there another limit to consider when working from desktops?

I agree. I also don’t recall such a seperate discussion between Apps and Pages in regards to the 25K limit.
I understand the distinction between Apps and Pages in the sense that Apps is meant for a more “small screen” solution, while Pages are for all screen sizes. However, I’m still fairly enjoying the wider freedom we have with Apps. I do have Apps that will actually be used mostly from desktops.
BTW - Do we know if (and when) we would be able to convert Apps to Pages, and vice-versa?


PS - ouch, that hurts :stuck_out_tongue:

Pages use a more efficient computation model, which is coming to Apps soon, which improves performance for projects with more rows, but doesn’t get us to 100k rows.

It’s not really the number of rows, so much as the computational complexity created once you add Rollup columns–you can quickly create computed columns that rely on multiple tables, creating O(rows²) or O(rows³) computations (computations that scale with your number of rows squared or cubed, for two and three Rollup columns, for example).

Future versions of Glide will move Rollups and the rest of the computation model server-side, where we can use machines with significant RAM, and download only the results of computations to your device. We may also introduce ‘Big Glide Tables’ that cannot be the source of Rollups, and may have other limits, that allow them to scale to millions of rows.


An example is that a couple of years ago, I made a test app with 120k rows. Very simple and only a couple of columns. However, I attempted to display all 120k rows in a single list. The shear amount data that had to be downloaded and rendered on the screen brought my phone, as well as my laptop to it’s knees. Like @david said, computations and rendering begin to compound very quickly, especially when you are loading an entire database on a user’s device, and making their cpu/ram do all the heavy lifting.