Airtable automation limits, and when to move to Make, n8n or code
Airtable's automations are good at what they were built for: a triggered write or notification inside one base. They are not an integration platform, and the usual failure is asking one to be. The limits are real but vary by plan and change over time, so rather than printing numbers that go stale, this article names the categories, the symptoms they produce, and where each one points.
By Saveez IrfanUpdated
In short
- Keep native automations for triggered writes and notifications inside one base. They are the right tool there.
- Move to Make or n8n when the work involves several systems, retries, loops, or a failure you cannot diagnose from the run log.
- Record limits and API limits are per base and per plan. Check Airtable's current limits against your growth, since the figures change.
- Writes through the API go ten records at a time under a per-base request rate, so integrations need chunking, back-off and idempotent retries.
- Move to a database with code over it when concurrent writers and real integrity constraints matter. Airtable does not let you wrap several writes in one transaction.
The limits come in six categories
We deliberately do not print Airtable's quotas here. They differ by plan, they change, and an out-of-date number is worse than none. Read Airtable's current plan and limits pages before sizing anything. What is stable is the shape of the constraints.
| Category | What you hit | Symptom |
|---|---|---|
| Automation runs | A monthly run allowance that depends on the plan, with failed runs counting as well as successful ones | Automations stop firing near the end of a busy month |
| Automation size | Limits on the number of actions per automation and automations per base, and on how long and how much memory a script step gets | A script that worked on ten records times out on a thousand |
| Record limits | A record cap per base that depends on the plan, plus a separate attachment-space allowance | You reach the attachment allowance or the record cap sooner than you planned for |
| API rate | A per-base request rate, and writes in batches of ten records | A bulk push drops writes or crawls |
| Observability | A run log that is useful and shallow | You know it failed and not why |
| Integrity | No way to wrap several writes in one transaction, and no joins across bases | Two writers both succeed when only one should; cross-base reporting needs synced tables or an export |
Notice that most of these are not bugs. They follow from what Airtable is: a relational database with unusually good views on top, which is not a query engine, an integration platform or a transactional store.
What native automations are right for
Native automations are the right tool for triggered writes and notifications whose whole life is inside one base. When a record reaches a status, stamp a date, notify the owner, create a linked record. They have no extra credential and no extra platform to understand, though their runs count against your plan's monthly allowance, and the people who maintain the base can read them.
- Notifications when a record changes state.
- Stamping a date or setting a field when a record matches conditions.
- Creating a linked record in another table of the same base.
- A short script step where the logic genuinely needs one and the data is small.
Anything computed should be a formula, rollup or lookup, not an automation maintaining a stored number that can then be wrong. Many automations in the wild exist to do what a field definition could do declaratively.
Symptoms, and where each one points
| Symptom | Move to | Why |
|---|---|---|
| The automation must call two or three other systems and handle their failures | Make | Routers, error handlers per module and a run history you can read |
| The same logic runs at a volume where per-operation billing hurts | n8n, or execution you control | Execution is metered differently, or not at all |
| A script step times out or needs more data than it can hold | A service, or an n8n workflow with paging | Page the source and write in chunks |
| You cannot tell why a run did nothing | Make or n8n, where the run history holds each step | Diagnosing needs more than the native log shows |
| Two people acting at once must not both succeed | A database with constraints | Needs transactions the platform does not expose |
| Reporting needs joins across bases | Pipe the data to somewhere built for querying | A view is a saved question, not a query engine |
| The base is nearing its record cap with mostly old data | Archive to Postgres or a warehouse on a schedule | Decide the working set; keep Airtable for what people touch |
The API limits are where integrations quietly fail
The REST API takes ten records to a create or update call and enforces a per-base request rate. A naive integration that pushes a thousand rows hits both: it is a hundred calls minimum, and calls beyond the rate are rejected. If the integration does not handle that, it starts dropping writes, and a retry that is not idempotent then creates duplicates on top of the gaps.
- Chunk writes into batches of ten and read in pages.
- Back off when the rate-limit response arrives, rather than retrying immediately.
- Make every retry safe with a stable key and an upsert or find-or-create, so running it twice leaves the same result.
- Filter in the read, not after it. Fetching the whole table to find three rows costs rate budget on any platform.
- Alert when a run writes fewer records than it was given. Dropped writes do not raise errors of their own.
This applies whether the caller is Make, n8n or your own code. Our Blueprint Runner, which executes Make blueprints on infrastructure you control, supports the Airtable actions including search, create, update, upsert and arbitrary REST calls, and it does not remove these constraints. They belong to the API.
When the answer is a database and code
Some limits are not about volume. If integrity has to hold under concurrency, as with money moving, stock levels or anything where two people acting at once must not both succeed, you need transactions and constraints that Airtable does not expose. Neither Make nor n8n supplies them either, since they sit in front of the same store.
The trading ERP we built is the case for that side of the line. It has relational data with approvals that gate revenue, stock movement and a field-level audit log, and the rules live in Postgres: invoices in draft or under review are excluded from totals, and the audit table has no update or delete policy. The rules sit where an import, an automation or a person writing to the data cannot get around them. That is not an Airtable build, and we mention it as the example of what a base cannot enforce.
If you already have Postgres and someone who can build on it, the durable answer is an application over that data, with the views and forms people need, and not a second copy in a spreadsheet-shaped product. Airtable's advantage over a real database is the interface, not the storage.
Deciding
| If this is true | Then |
|---|---|
| The rule starts and ends in one base | Native automation or, better, a formula |
| It crosses systems or needs retries | Make for branching and transformation; n8n for volume or residency |
| It is slow because of long scripts or large reads | Page it and move it to a service or workflow |
| You hit record or storage ceilings | Decide the working set, archive the rest |
| Concurrency and integrity matter | A database with constraints, and an application over it |
| The core object is work moving through stages with an owner | Reconsider the platform. That is monday.com's shape, not Airtable's |
Most teams do not need to leave Airtable. They need to stop asking its automations to be an integration platform, and to design the base before it fills with data. Our Airtable page sets out the modelling side, and the Airtable vs monday.com article covers the choice between them.
Common questions
They fall into runs per month, the size of an automation and its script steps, record and storage limits per base, API rate and batch size, a shallow run log, and no multi-write transactions or cross-base joins. Exact figures depend on your plan and change, so check Airtable's current limits page against your volume.
Airtable automations for triggered writes and notifications inside one base. Make once the work involves several systems, branching, retries or failures you need to diagnose. Use both: native for the in-base rules, Make for the rest, with one system owning each field.
There is a per-base request rate, and create and update calls accept ten records at a time. We do not quote the exact rate because it is Airtable's to set and can change. Chunk your writes, back off when you are told to, and make retries idempotent.
The record cap is per base and depends on your plan, and attachments have a separate space allowance, so either ceiling can arrive before you expect. Check the current figures for your plan. The usual fix is to archive old records on a schedule and keep Airtable for the working set.
When you already have a database and someone to build on it, when integrity must hold under concurrent writers, or when the core object is work moving through stages with an owner, which suits monday.com. Otherwise you can usually stay and move only the automation logic.
Sources
Statements about what a platform does are checked against the vendor’s own documentation as of 2026-10-04. Vendors change things, so check the current page before you rely on a limit or a price.
- Getting started with Airtable automations · Airtable
- Airtable automation action: Run a script · Airtable
- Managing API Call Limits in Airtable · Airtable
- Airtable plans overview · Airtable
- Getting started with Airtable sync · Airtable
Drafted with AI assistance (Claude). Published under Saveez Irfan’s name, who is accountable for it. Editorial policy