Hi all. I am just checking out Glide. We are an organic fert company in New Zealand and need to move our soil data and quoting to a web based activitity. We have had our data storred in a MS Access DB for the past couple of year (don’t ask me why it was not my choice) but now we are moving into the 21st century.
My questions is if we are starting from scratch what are the pros and cons of building the database in Airtable and using Glide pages and Apps to access it as opposed to keeping everything within Glide and using the Glide tables… I have a Systems and accounting backgroud and not a coder or developer. We have to make a choice in the next week or so and don’t have a lot of time to play and find things out for myself.
Keep in mind that Google Sheets and Excel files are also available data source options.
I don’t have experience with Airtable. Others are using it successfully, but there are a few quirks compared to google sheets and excel. Especially if you are reliant on some of airtable’s built in features, such as linked records and custom views. Also, with the current integration that glide has to airtable, there are some issues with data coming into glide in a random order, as well as glide needing to perform synchronizations more often than usual to check for new data in airtable. These specific issues are not present with google sheets or excel tables, but if you use your airtable purely as a database, without trying to use some the the exclusive airtable features, then you should not have too many issues.
With Glide Tables, you don’t have to bother with any outside database as it all remains internal to glide. This is good, because you can eliminate any additional syncing that needs to occur between glide and those outside sources. But, on the other hand, you may want to use google scripts or any other automations that airtable, google, or excel may provide. It really comes down to personal preference. Which database are you most comfortable with, or which one provides the functionality that you need. You can always mix and match different database sources in the same app.
My primary app is built on google sheets. I could move a large chunk of it to glide tables, but haven’t felt the need yet. I have some functionality that can only be performed using google sheet formulas and google scripts and can’t adequately reproduce using glide features. For that particular app, google sheets works best for me. I have also built other apps that run entirely on glide tables and they work just as good for that need. I haven’t had a need to use airtable or excel yet.
I have used Google Sheets just for the simple reason that it gives others access to the data in a format that they are used to for producing reports. When Glide made Airtable access capable, I looked into it briefly but was turned off by the high “cost of doing business.” Excel appeals to me because I can use my programming skills to automate lots of processes.
Glide Tables certainly have advantages. The biggest disadvantage right now is that the API for outside processes to read Glide Tables has not yet been made fully available to all paid plans. You can currently write, delete and update but not read records. We’ve been told that is coming.
As @Jeff_Hager said, you can have Apps and Pages that utilize different databases for different uses. I have one app where all common tables (shared by all users) are in Glide Tables, and those that are specific to individual users are in Google Sheets and use row owners. That was so I would have an easy way to purge inactive users’ data out of the system.
That app was built before Glide had Excel, or I would have used that. I look forward to the day I can implement the entire thing in Glide Tables with the assistance of the Glide API.
Since you are starting with MS Access, you have the advantage of exporting your tables to CSV and then importing them into whatever database you feel most comfortable with. Many users are “locked into” either Google Sheets or Excel, or Airtable because that is what format their company comes from.