Your automations competing with your customers
Airtable gives a base 5 requests per second. That ceiling covers every caller at once: the nightly sync, the partner integration, a dashboard someone left open in a tab, and the customer waiting on a page to load. Nothing in the platform lets you say which of those matters more. When your internal work gets busy, the customer-facing request is as likely to take the 429 as the batch job that caused the problem.
One bucket, every caller
The published figures are the same on every plan. Airtable's API allows 5 requests per second per base, plus a separate cap of 50 requests per second for all traffic using personal access tokens from a given user or service account. Cross either one and you get a 429 and have to wait 30 seconds before requests succeed again. Thirty seconds is a long time to hold a checkout.
The monthly side is where the sharing gets concrete. The Free plan includes 1,000 API calls a month and the Team plan 100,000. Airtable's own help centre says third-party integrations consume the same monthly Public API quota as your own calls, so the Zap you built last spring, the partner's nightly pull and your production app all draw down one number that none of them can see.
The Team overage behaviour is worth reading twice. Pass 100,000 calls and Airtable slows the workspace to 2 requests per second until the first day of the next calendar month. A busy month earns you a 60% throughput cut, applied to the same customers who made it busy. Airtable also states the monthly cap is fixed per workspace plan and cannot be raised on a per-account basis, so there is no support ticket that fixes this one.
The automation layer bills the same way
Zapier counts a task each time an action step runs successfully, while triggers and filters cost nothing. The Free plan covers 100 tasks a month and Professional starts at $19.99 a month. Hit the ceiling and Zapier holds the runs instead of dropping them, and you can replay them from Zap History once tasks are available again. Held beats lost. It still means the work is not happening while you are over.
Polling is where the plan tier shows up in latency. Zapier checks for new data every 15 minutes on Free, every 2 minutes on Professional and every minute on Team. When a workflow feels slow, the lever is a bigger subscription rather than a change you make. Make works on credits, one per module action, with 1,000 credits a month on Free and a 15 minute minimum interval between runs.
Make's unit price climbs as you grow. At the 10,000 credits a month tier, Core is $9 and works out to $0.90 per 1,000 credits, Pro is $16 at $1.60, and Teams is $29 at $2.90. The money on the higher plans buys priority execution and team roles, so throughput gets more expensive per unit as you scale rather than cheaper, which is the reverse of how a server bill behaves. Make's own API is capped per minute by plan as well: 60 calls on Core, 120 on Pro, 240 on Teams.
Separating the callers
Postgres hands each caller its own identity and its own budget. CREATE ROLE accepts a CONNECTION LIMIT. ALTER ROLE accepts SET for any configuration parameter, which becomes that role's session default at login. The batch importer connects as a role with a small connection allowance and a generous statement timeout. The customer path connects as a role with a short one. The import can saturate its own pool all afternoon without reaching the pool the checkout draws from.
That is the entire difference. Both systems have limits, and one of them lets you choose who gets throttled first. When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the Lighthouse score went from 55.91 to 91 out of 100 and LCP came down 77%. The thing that mattered more over the following months was quieter: the back end became something we could tune per caller instead of per invoice. A four stage ETL carried the legacy record IDs across as PostgreSQL UUIDs, so the integrations hanging off the old system kept resolving.
You inherit the capacity planning along with the control. Nobody emails you at 80% of your quota, because there is no quota to be at 80% of. You discover you are short on connections when the pool starts queueing, which means somebody has to be watching the pool. A platform limit is at least a number a vendor counts on your behalf, and that is a real thing to give up.
When one bucket is the right size
Most bases never come near 5 requests per second. An internal tool that six people read, with one nightly job attached, will not notice the ceiling, and on Business or Enterprise Scale the monthly call allowance is unlimited, which leaves only the per-second limit you were not hitting anyway. Rebuilding a backend to escape a limit you will never reach is the expensive kind of mistake.
Volume on its own is not the signal. The question is whether you have ever scheduled internal work around customer traffic. The afternoon someone moves the sync to 2am so the dashboard stays responsive during business hours is the afternoon the shared quota started costing you something you could measure. Until that has happened, the ceiling is theoretical, and you should stay where you are and spend the money on something that is actually hurting.
