Is there any documentation for MySQL that I can get access to.
Once you move to MySQL then does that eliminate all performance/scalability limitations that you get with the google sheets (25k rows) or are there still things we need to consider, things specific to Glideapps
Do we have control/access of the MySQL instance ? Do we set it up and then give the connector details to Glideapps or does Glideapps have full management control over it
Do we get access to CRUD APIs to the database and/or can we also write our own APIs for it and build other Apps/tables to look at the same DB if we need to extend the capability of the app beyond what we may be able to do inside Glideapps
Sure @Ian can give further details about it but according with what I know:
performance/scalability limitations: yes, now your new limitations/benefits are based on what MySQL can have and handle which are much better than GS or GT
MySQL instance: yes. You will have total control over your MySQL instance (your DB hosted by you): users, tables, permissions, etc.
CRUD: I suppose so! You will have the same standard access and functionality like any other DBMS software (database management system) without necessarily creating custom APIs.
Is there any documentation for MySQL that I can get access to.
Not at this time.
Once you move to MySQL then does that eliminate all performance/scalability limitations that you get with the google sheets (25k rows) or are there still things we need to consider, things specific to Glideapps
No. Performance is similar to Glide Tables, and you are still limited to 25k rows within the apps.
Do we have control/access of the MySQL instance ? Do we set it up and then give the connector details to Glideapps or does Glideapps have full management control over it
You set it up and then give the connection details to us. We actually do not provide a MySQL instance for you. We built the MySQL integration for large companies who want to connect to an existing MySQL database hosted in Google Cloud SQL.
Do we get access to CRUD APIs to the database and/or can we also write our own APIs for it and build other Apps/tables to look at the same DB if we need to extend the capability of the app beyond what we may be able to do inside Glideapps
You would host it so, you would have full access to it.
A broader note: we built the MySQL integration for Enterprise customers that have existing large databases that they need to read/write to and Google Sheets isn’t an option.
The 25k row limit is still in place and is handled with a date filter or something similar. E.g. “WHERE date < last_90_days”. You still have to work with our engineering team directly to implement this as well, it’s a pretty heavy implementation more suited to big companies with a data admin.
For most folks, I recommend Glide Tables if you’re looking for better scale and performance. If you have a huge existing database you want to connect to, talk to me about MySQL.
At some point, we’ll make MySQL more accessible so that everyone can access a larger database, but that’s not on the roadmap at this time.
Isn’t it like google sheets, where the data is pulled into and stored in glide (ie. a sort of glide table). I assume it’s the same situation with mysql. It’s not reading the sql db directly, but syncing between the glide servers and the sql db, just like the sync between google sheets and glide works.
Your biggest limitation is going to be how much data you are trying to sync between glide servers and the user’s device. Pushing 25k+ rows of data to each user gets to be a lot. Apps don’t communicate with google sheets or mysql. They communicate and sync with glide’s copy of the the database on the glide server. From there the server syncs to google or mysql.
I assume the Excel implementation will work the same way.
Thanks and understood makes sense and answers many other potential questions/queries for me.
So question for the all app devs, how do you stay within the 25k rows limit ? Are you offloading to external systems using webhooks ? deleting data etc… Or being very selective of what you are storing (i.e minimal logging, audit, history etc…)
Are there any performance indicators that tells you if you are close to the performance limit.
I have hardly ever hit 25k rows for my clients but to answer your question, for the very few cases we have at our agency, we have an external sheet/spreadsheet to store the historical data and only keep the new ones.
For indicators, I think the most obvious one is the row count. We have an app with like 13-14k rows and a lot of computational columns, the builder is super slow. On one app we do reach 25k rows, it’s like 1/4 the speed of a normal one.
There isn’t really a good answer. I agree with @ThinhDinh, it all depends on the app. Just consider that ALL data has to be synced to the user’s device, with the exception of row owner protected sheets and the data that does not belong to the signed in user. These apps are more or less synchronizing the entire database onto each user’s device. Add to that any computations that need happen. This includes any glide columns, such as relations, lookup, rollups, If, math, etc. That also happens directly on the user’s device. If you are synchronizing a large portion of the database and then running calculations or anything else on those computed columns, then it is going to cause some performance issues. I think you can get away with a lot as long as you are mindful of what is happening behind the scenes. This isn’t like a normal website where you make a server request and wait for a response. Instead everything is happening in real time directly on the user device to give much more of an app-like experience. Of course, that data is then synchronized with glide servers, but that takes place over a few seconds behind the scenes.
@Jeff_Hager If I have a sheet with 20,000 rows of data in it, but only 10 of those rows belong to any given user, then that user will only download 10 of those rows. The limitation we are discussing is based on the rows that need to be downloaded to the client/user app and not the total number of rows in a sheet, is that correct ?
Correct. Only 10 rows would be downloaded to the user’s device. So from their side, the app should be very responsive. If the data is being kept in a google sheet as opposed to a glide table, then there is the added overhead of the glide server and the google sheet having to stay synchronized. It should be fine, but consider that bottleneck. I think a lot of the 25k theoretical limit is due to bottlenecks with the google API. Moving as much as you can to glide tables will eliminate that extra path that the data has to travel.
My primary app is still google sheet based, but I’m only at around 7500 rows. I likely won’t migrate much of the data away from google sheets because I perform weekly backups of the data with google scripts to have a readily accessible backup of the data if needed. However, most calculations have been moved to glide. I have a few things that I still can only do in a google sheet. As new glide features are released, I try to incorporate them into my app to try to trim the data in the sheet. The app has one primary user that uses most of the functionality and another user that mostly just views some of the data here and there. My primary user does run into some speed issues only in certain parts of the app, but that is mostly due to owning a large portion of the data and me having most of the data readily accessible so it’s searchable in the app. My app also has what I consider intense calculations and several relations because it performs lesson tracking, billing, and invoicing dynamically. I have yet to find the best way to structure it so there is no lag, but I don’t think any of the lag issues are due to google sheets at this point other than some data taking a bit longer to synchronize from the google sheet back to glide. I wouldn’t say that I have a large amount of data, but it does do a lot with the data that’s there, and I’m impressed with what it’s capable of. Anything that is slow is expected due to what I’m demanding of the app.
