I went through something like this. I was thinking oh... airtable saves me from having to develop the crud aspects of my app! Boy was I wrong.

For super super basic stuff, Airtable is fine to code against their API. But as soon as you get into anything more complicated, you are going to get screwed.

They have a 5 concurrent connection limit and no real transactions. Want to insert 6 rows quickly across two tables? Nope. I guarantee that despite all your best effort, you will have inconsistent data. At a high level, their api is nice and simple, but that is it. It doesn't go deeper than that.

You are VASTLY better off building against a real SQL database. If you want to visualize the data in Airtable, then export it there from your SQL database.

This is a great concept! I'm not surprised to see you getting flak for building on Airtable, but as a "real developer" leaning heavily on low/no code lately I wanted to share how well it's worked for our open source team over the last few months.

In terms of scale, it has supported dozens of editors, hundreds of public submissions, and several thousand rows of data. We have also successfully scripted a number of use cases using the API for workflows that can be automated.

The biggest benefits from my perspective are:

1. Minimal overhead for schema changes. We have been able to overhaul our schema on more than one occasion with no intervention from developers up front. We let the content team shape the data in a way that makes sense then update our client code to fit

2. The UI is obvious to technical and non-technical users alike. Who doesn't know how to use a spreadsheet?

3. No-code workflows are trivial to prototype and launch with blocks and forms.

Is it going to work forever? No, we're already moving the more stable+dynamic tables into a SQL database. But I'm sure that we've saved dozens if not hundreds of hours of time in our frequent iterations these first few months. I'm sure we'll keep using Airtable for new features.

[0]: https://climatescape.org/ [1]: https://github.com/climatescape/climatescape.org

I already use Airtable as a backend for some small internal tools. It definitely does the job but there are some moments where I feel it might be easier and more flexible just to create something on Firebase. From an API perspective storing and retrieving objects in both is equally as easy.

The only reason I went with Airtable is because I needed a GUI to add data manually.

I see a lot of people talking about SQL or Airtable. But there's a third middle ground here - Graphql based headless CMS.

For example Graphcms, Prismic, etc. You get the standardization of Graphql (which means no lock-in) and pretty much as powerful as SQL really.

You also get the admin/dashboardy/WYSIWYG aspects of a CMS - https://prismic.io/feature/custom-type-builder

Very easy integration - https://medium.com/better-programming/graphql-combine-and-sw...

(of course this works just as well on Android, React Native/Web,etc)

Airtable-as-a-Database is absolutely delightful. It comes with an advanced admin back-end for other team members to view and manage data. For many apps, instead of starting with RDBMS tables, I consider Airtable and strategically move to an RDBMS where Airtable doesn't scale (organizationally, latency, security, row-count, etc.)

I've most recently built https://design.org using Airtable. I think it's performant and rock solid. It saved some initial development time, but the benefits have kept coming.

Oh very cool! Love the idea of using a third-party service to store data for simple projects, mobile apps included!

If anyone is looking for a similar solution, a place to dump data for personal projects, check out Pantry (https://getpantry.cloud/). It lets you store JSON and has a simple API.

You might wanna consider FaunaDB if you want to make the backend a bit more database-like but still serverless.

Their GraphQL API is neat.

I built an ERP-like application for a small production company entirely with Airtable as the backend, but wrapped in a GraphQL schema. The Airtable app fetches the schema of a base when you load it, complete with all type columns, data types, select options, lookup ids, etc. You can use that to generate a GraphQL schema and fetch the data from Airtable in your resolvers. The rate-limiting and general speed when fetching a lot of data makes it unsuited for things that need to scale, but having the excellent Airtable UI for raw data entry and a custom application for everything else (complex data entry, reporting, kpis and such) was very nice.

That said, if I were to do it again today I'd probably go with Hasura or something more suited as an actual backend.

This is really cool! I’ll definitely take a look at this and maybe fork it when we get onto looking at native apps.

We have built a web app (https://stacker.app) for people who want to use an Airtable backend.

Just an FYI, if anyone doesn't realize, any images or files you upload to Airtable, aren't protected in any way, if you happen to get the URL.

It's been like this for years, and recently confirmed it's still the case.

Something I haven't seen mentioned is how great their API documentation is. Each database (AKA "base" in Airtable parlance) gets a generated set of docs that uses the actual names of the tables and fields (and the field types), as well as javascript examples that use your real data as sample output values.

This is really cool. I've used google sheets as a backend/UI for a client project once. Worked really well. People know how to use it and it scales for "most" use cases.

This is VERY useful to build a MVP FAST / TEST the market. I would love to try it for an idea I am about to test. Instead of using WP i can use this method.

I run my life on an Airtable GTD framework. I'd totally skin a iOS build to improve on the experience.

Nice work!

I've been exploring using AirTable as a potential back-end for read-sometimes/write-rarely data.

What is Airtable? Seems like something that should’ve been mentioned.

Impressive work.