"Backend" database. Airtable v Glide Tables

Hello all

Keen to hear everyones thoughts on the below.

I have used Airtable for years - and find it extremely powerful as a database. I have invested too much time and have too much data in it to ditch it completely.

Regrettably - the front end options for Airtable are both expensive, and rubbish. So I therefore use Glide as a front end - with all the data in Airtable in the back end.

I prefer doing this for a few reasons - but there are obviously a few negatives too. I would be very interested to hear everyone’s thoughts.

Positives of using Airtable as a back end

  • Much easier to wade through lots of rows of data. If I am debugging for example, I can create a specific view (set of filters, sorts, groups) so I can drill down into the data and find something. For example, I use Airtable to track finances for one of my projects. It has approx 2,000 rows, several suppliers, budget columns with roll ups etc. I can’t imaging building something like that in Glide as I am regularly trying to find something specific.

  • I love Glide, but it is not the be all and end all. There are other front end solutions that work with Airtable. Keeping my back end separate means I can try out other front end solutions that work with Airtable (of which there are many - all with different strengths and weaknesses)

  • Having all my raw data in one place, means I can back it up easily

  • Airtable as a database is much more powerful with formulas, automations etc. Granted - this makes the sync between Glide and Airtable slow - but still useful.

Disadvantages

  • I have to subscribe to Airtable (Approx ÂŁ30 p/month) and Glide separately
  • Syncing is slow. I have to adopt a few work arounds at times - particularly when it comes to relations.
  • Glide have removed Airtable as an option from their Maker plan

I know people are creating Glide apps, using Glide tables for data storage that are far more complicated and bigger than mine - so am I missing something? Is it time to ditch Airtable as a backend and just use Glide tables (I would not need Glide Big Tables)

Thoughts welcome!

Andrew

PS - I should add, I am not a professional developer - I run my own event management business and like using apps like Airtable / Glide etc on my own projects. I don’t charge for them

Pro-tip:

I have a master Airtable base with 15+ tables and over 300 columns in total. I first synced this base with Glide, and after 2-3 months of developing, Glide started to crash and the database wouldn’t update AT ALL. I had to start over.

So I used Airtable’s base-syncing feature and split the main base to sync different tables into different bases. Turns out, I actually need only a few tables, and also only certain columns in each table. So I also only synced the columns I’d need in the new bases. Note that Glide cannot edit 2-way synced fields in Airtable for some reason, so as a work-around I created another column inside the new base (which Glide can edit), and then used two Airtable automations to sync the original and the new columns whenever there are changes in either column.

Another pro-tip, I’m now linking tables inside Glide using Glide’s relational field instead of relying on Airtable’s linked field, and using lookup in my tables as needed. That way, I don’t have to wait for Airtable’s sync to happen, since the relational field is in Glide and changes in lookup values happen instantly.

The end result was that in the 1st setup, manually syncing one Airtable would take over a minute. Now it takes around 5 seconds even when I have 6 Airtable sources.

Combining Airtable + Glide seems like a good win-win, because I can offload a lot of formula columns and automations inside Airtable and hide those columns so that they’re not synced to Glide. Meanwhile, Glide allows user-specific columns in these tables which is immensely helpful and isn’t available in Airtable interfaces.

1 Like

In my opinion, don’t ditch Airtable. I too have been using it for over 6 years, and pretty much everything is in there, from finances to HR. I don’t want to ditch Airtable for the same reasons you mentioned, and they’re very good reasons too (keeping backend separate, powerful data manipulations via formulas and automation, lots of integrations since Airtable has been around for so long).

So keep Airtable, and use Glide only as the front end with some additional Glide tables and columns to help speed up syncing by not loading too much info from Airtable. I can assure you that after using Softr, Adalo and Glide for 3-4 years, Glide is miles better now than the other ones. It’s a shame that the new pricing has made it more expensive, but it’s still worth it.

Also, don’t use only Glide. You won’t be able to use a lot of the native integrations that Airtable has, and also Airtable automations are extremely useful, which Glide doesn’t fully have yet. Also, Airtable seems (to me) more future-proof than Glide, so keep Airtable as the back-end and use Glide as the front-end.

1 Like

Thanks for sharing, those are some key insights. I only have one app with Airtable till now and I agree with all your points there.

1 Like

Great post @Jarvis

Glad that there is someone else still using Airtable with Glide. I’ve already got sync’d bases. One of my Airtable bases, when I originally sync’d with Glide, destroyed my row and storage quota. There was a lot of data in there I didn’t need in Glide so I set up a sync’d base the same way you do. I’d avoided adding columns to the sync’d base as I wanted to keep it simple but may give that a go.

I understand why basic columns added in Glide can’t sync back to Airtable, but don’t understand why they have to be user specific columns. Useful sometimes, but not always.

I assume, when adding rows from Glide, you add them directly to the main Airtable base. Is there a delay seeing them appear in Glide?

After a chat with Glide last week, I feel more comfortable using just Glide, but some of my Airtable bases are just too big and complex to transition.

Thanks again
Andrew