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.
> I wouldn't recommend using Airtable to store fast-moving data but as a means of storing strings, images, positions of views, and general data that won't get updated very often, Airtable could be a potential option for you.
At the end of the day, I knowingly made the decision to experiment with it. I learned a bunch from it. Glad I did it.
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
If you want more: https://linkedin.com/in/zackshapiro
The only reason I went with Airtable is because I needed a GUI to add data manually.
Never got to use it because I'm mainly running on DynamoDB, but heard lots of good things about it
P.S: Saving a Google search for people who come across this thread: https://www.forestadmin.com/
Remember getting an error because a document was getting updated too fast (four or five times in less than a second).
Heck, their own documentation states a document can only be updated about once (1) per second[0]
[0]: https://firebase.google.com/docs/firestore/solutions/counter...
A regular SQL database and a good ORM is so much more productive. Servers have terabytes of RAM these days.
We've found that Hasura offers us the best of both worlds. It doesn't actually store any data itself, it's "just" an API layer on top of postgres. So we can do most things with bog-standard SQL-backed REST APIs, and with a couple of clicks to set up relations and permissions in Hasura we also access any of that same data through realtime-capable GraphQL api.
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)
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.
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.
Their GraphQL API is neat.
That said, if I were to do it again today I'd probably go with Hasura or something more suited as an actual backend.
We have built a web app (https://stacker.app) for people who want to use an Airtable backend.
It's been like this for years, and recently confirmed it's still the case.
I've been exploring using AirTable as a potential back-end for read-sometimes/write-rarely data.