Upcoming database upgrades. Airtable functionality will be reduced for ~15 minutes at 06:00 UTC on Feb. 4 / 10:00 pm PT on Feb. 3. Learn more here

Same database, slow API

Topic Labels: API
566 2
Showing results for 
Search instead for 
Did you mean: 


I am investigating an issues with response time from Airtable REST API and I need some help with a strange behavior I am getting.

We use the API a loot to integrate our database with clients using a GraphQL > Airtable proxy developed by us and recently we are getting a loot of requests with high response time wich causes a loot of response timeout in our serverless endpoints.

Bellow are some requests I made on our MASTER database:

→ Catálogo
GET /v0/app0U83sn3JtVRfrH/Cat%C3%A1logo?pageSize=32 [200 OK, 20.56KB, 9.7s]

→ Catálogo/ID
GET /v0/app0U83sn3JtVRfrH/Cat%C3%A1logo/rec05hJb37zHtFj4D [200 OK, 2.01KB, 16.7s]

→ Pedidos
GET /v0/app0U83sn3JtVRfrH/Pedidos?pageSize=18 [200 OK, 13.71KB, 6.8s]

→ Pedidos/ID
GET /v0/app0U83sn3JtVRfrH/Pedidos/rec04Tl5QF1bg5MZP [200 OK, 2.46KB, 4.1s]

→ Status dos Pedidos
GET /v0/app0U83sn3JtVRfrH/Status%20dos%20Pedidos?pageSize=91 [200 OK, 55.56KB, 4.2s]

→ Status dos Pedidos/ID
GET /v0/app0U83sn3JtVRfrH/Status%20dos%20Pedidos/rec0Vc9mFOCVYWNma [200 OK, 2.67KB, 3.4s]

→ Insiders
GET /v0/app0U83sn3JtVRfrH/Insiders?pageSize=66 [200 OK, 24.92KB, 5.4s]

→ Insiders/ID
GET /v0/app0U83sn3JtVRfrH/Insiders/rec084ZncvmpRtsCW [200 OK, 3.1KB, 2.3s]

As you can see, a loot of 5s and all of it is higher than 2s.

To start my investigation first I have made a clone of our database using the duplicate feature from Airtable, which I know duplicate all tables, fields and data and do not duplicate history for records, and I am OK with that. The main idea with the clone is to see if any of our formula/rollup fields are the main performance issues.

But with the cloned database I get this strange behavior, when running them same requests above the response time are much more better, see:

→ Catálogo
GET /v0/appIjEDB0CWbClFmr/Cat%C3%A1logo?pageSize=14 [200 OK, 11.49KB, 1089ms]

→ Catálogo/ID
GET /v0/appIjEDB0CWbClFmr/Cat%C3%A1logo/rec02DVhH0eaAQzoR [200 OK, 1.94KB, 480ms]

→ Pedidos
GET /v0/appIjEDB0CWbClFmr/Pedidos?pageSize=52 [200 OK, 36.1KB, 505ms]

→ Pedidos/ID
GET /v0/appIjEDB0CWbClFmr/Pedidos/rec0AODZLPJa0n15U [200 OK, 2.37KB, 247ms]

→ Status dos Pedidos
GET /v0/appIjEDB0CWbClFmr/Status%20dos%20Pedidos?pageSize=78 [200 OK, 48.28KB, 524ms]

→ Status dos Pedidos/ID
GET /v0/appIjEDB0CWbClFmr/Status%20dos%20Pedidos/rec0V2mEsLcmMNpZz [200 OK, 2.14KB, 205ms]

→ Insiders
GET /v0/appIjEDB0CWbClFmr/Insiders?pageSize=91 [200 OK, 31.6KB, 1188ms]

→ Insiders/ID
GET /v0/appIjEDB0CWbClFmr/Insiders/rec0FMWt2JBk6Sccb [200 OK, 2.8KB, 248ms]

Can you people help me identify why this clone database with same data, tables and fields perform much better than the original one?


2 Replies 2

Got a little progress here, in MASTER database disabling all automations reduced the times as the CLONE.

After further investigation I found the automations relying on changes to formula fields add the most time to response perfomance and I changed this fields to single line text and make the formula an automation to update this field when records changes. Now the times are much better.

Hey @Rodrigo_Moyle ,

Sounds like you already got to the root of it. Thought I’d drop this here as well in case you were interested. Did a deep dive on what elements in an Airtable base most affect API write performance. I didn’t investigate automations, but did find some interesting results with computed fields like rollups and formulas: