Ha ha! No one is that familiar enough with Airtable’s backend. There are many mysteries and we can only speculate in most cases. However, they have confirmed some of the speculations concerning performance, an issue that has plagued successful apps for years.
Bottlenecks are typically self-inflicted wounds caused by no-coders who want instant integration gratification. The use of glue-factory services such as Zapier allow no-coders to [seemingly] scale solutions, but at a cost that usually creates more pressure on the Airtable instance than would otherwise be the case if a clean event-driven approach were fabricated.
We can’t blame Airtable’s no-code customers for this; the event architecture of Airtable has been been sluggishly exposed over the past few years.
Certainly, an iteration component in Airtable’s automation feature would be far better than iterations performed in Zapier because Zapier recipes typically fire amidst a barrage of polling requests to the API. This insanity could/should be avoided and performing iterations closer to the data would potentially eliminate hundreds of thousands of API requests.
It’s in Airtable’s best interest to give Zapier a comprehensive event architecture or obsolete Zapier by making it all possible inside the Airtable SDK via script automations. There is already evidence low-coders are avoiding glue-factory solutions through clever script automations.
