I have internal classic apps that share a bunch of Glide tables, including the user table. There is also a common Google sheet attached, with a couple tabs, mostly for the ease of accessing for integrations using Zapier. I got burned recently using JS in Zapier and until Zapier makes it as easy to search a Glide table as it is to search a Google Sheet (including computed columns!), I’m going to avoid that.
Question is, how much downside would there be to change the user table, and possibly a heavily used services table, from Glide Tables to Google Sheets. It would be a ton of work, for the sole purpose of making integrations easier and reducing duplication of a couple tables. Based on experience with this sort of thing, would you say
There would be heavy performance penalties
You’d hardly notice
It depends, and you’re going to just have to try and see
I would say it depends, and you’re probably going to have to test it, but I would not expect a dramatic performance penalty in most cases.
The biggest factor is not just the number of rows, but how the tables are used. Glide Tables are generally faster and more native because Glide controls the data layer, sync, and queries. Moving a heavily used table like Users to Google Sheets can introduce more latency, especially if you have:
lots of computed columns
frequent updates
many relations/lookups
workflows that trigger on changes
large tables with many rows
For a User table, I would be cautious because it is usually referenced everywhere (roles, permissions, filters, relations). A small delay there can affect the whole app experience.
For a Services table, it depends more on how dynamic it is. If it is mostly reference data that changes occasionally, Google Sheets can work very well and the integration benefits may outweigh the downside.
One thing I would consider before moving everything is a hybrid approach: keep the core operational tables in Glide Tables and maintain dedicated integration tables in Google Sheets. Use automation to sync only the fields needed externally. That avoids duplicating everything while keeping the app fast.
Also, be careful about moving just to make Zapier easier. Sometimes the better long-term solution is improving the integration layer rather than changing your database structure. Google Sheets is excellent for integrations, reporting, and external workflows, but Glide Tables are usually better as the primary app database.
My expectation would be: you may hardly notice for smaller/simple tables, but heavily used relational tables are where you are most likely to feel the difference. Test with a copy first before committing to a full migration.
One thing to also consider is that when moving more data into Google Sheets, Glide can charge based on updates/sync activity with external data sources like Google Sheets, so increasing the dependency on Sheets can sometimes increase sync usage rather than reduce it.
In many cases, a better approach is to keep the app architecture optimized and build custom integrations where needed. I usually create customized integrations and API connections that move only the required data between systems, instead of relying on Zapier for every workflow. This can eliminate many Zapier steps, reduce unnecessary Glide sync activity, and give much more control over when and how data is transferred.
The goal is not just making integrations easier, but designing the data flow so the app stays fast, reliable, and cost-efficient.