Airtable limits: record caps, API limits and when to move on

Airtable stops scaling for a business at four specific points: the records per base cap (1,000, 50,000 or 125,000 depending on the plan), the API rate limit of 5 requests per second per base, the monthly quotas on automation runs and API calls, and per-editor pricing that grows with every colleague who needs to change a record. While you stay under those ceilings, Airtable is a great tool. When your core processes start working around them, it is time to look at a custom application.

This guide lists the limits as published by Airtable on 6 November 2026, what actually happens when you hit them, the workarounds and their hidden costs, when to stay put, and how to migrate without disrupting your team.

Airtable limits by plan (checked 6 November 2026)

Figures come from Airtable's plan documentation and pricing page. Airtable revises them regularly, so check before you decide.

Some limits apply on every plan, per the same documentation: 500 fields per table, 1,000 tables per base, 1,000 views per base and 1,500 bases per workspace. Enterprise Scale is sold on quote and its limits are not published. The figures you will see quoted on third-party blogs are not confirmed by Airtable itself.

Two details matter more than the headline numbers:

• The record limit is cumulative across tables. A 50,000-record Team base might be 30,000 orders, 15,000 products and 5,000 customers, not 50,000 of each.
• Once a base is over its limit, you cannot add records until you upgrade, according to the pricing page. Automations and API usage stop at the monthly quota.

What hitting each limit looks like in practice

Record cap

The first symptom is usually a form that stops accepting submissions or an import that fails halfway. Teams react by archiving last year's data to a second base, which works until someone needs a customer's full history or a year-over-year report.

API rate limit

Airtable's developer documentation caps traffic at 5 requests per second per base on every plan, and at 50 requests per second for all traffic from one user's personal access tokens. Exceed it and the API returns a 429 error; you then need to wait 30 seconds before requests go through again.

Manual data entry never gets close. But an online store pushing orders, an accounting sync running every minute and a dashboard re-reading everything can easily share those 5 requests, and every 30-second lockout delays the whole chain.

Automation and API quotas

On Free and Team, API calls are capped per month across the workspace, and automation runs are capped on every self-serve plan. A busy month, or one badly designed automation that loops, can use up the quota and silently pause everything else that depends on it.

Per-editor pricing

On Team and Business, Airtable bills every user with edit rights on at least one base. Read-only collaborators, form submissions and share links are not billed. Working from list prices with yearly billing:

For five people that is cheap. For forty, it is a budget line worth comparing every year with the cost of a tool designed around your process. Our guide to custom business application cost lists what goes into that other side of the comparison.

Workarounds and their hidden costs

None of these is wrong on its own. The warning sign is when a process that runs your business depends on two or three of them at once.

Seven signs it is time to move to a custom app

1. Data is split across bases just to stay under the record cap.
2. Useful data gets archived to make room, and people lose history.
3. Syncs fail on the API rate limit or the monthly automation quota, and someone restarts them by hand.
4. You need row-level access. A sales rep should see only their accounts, a subcontractor only their jobs. Airtable's sharing works per base, interface or view, so teams end up duplicating data.
5. Data quality keeps slipping: duplicate customers, statuses typed three different ways, required fields left empty.
6. One person built the base, its formulas and scripts, and nobody else can safely change it.
7. The editor bill grows faster than the business, because everyone who needs to tick a box becomes a paying editor.

One sign is usually fixable inside Airtable. Two or more on a critical process (orders, field jobs, billing) is worth a proper look. Our guide to replacing spreadsheets with a custom application describes the same pattern one step earlier.

When to stay on Airtable

Do not move just because a vendor says so. Stay if:

• your volumes will remain far below the caps for the next few years;
• the process still changes every month, and you value changing a field in two minutes;
• a small team uses it and needs flexibility more than strict rules;
• the data is not sensitive and per-base sharing is enough.

A well-used base is also the best specification you will ever write: its tables, fields and views show exactly how your team works.

Airtable vs another no-code tool vs custom

Our comparison of an agency, a freelancer or no-code goes deeper into each route, and the story of moving from Bubble to custom code covers the same transition from another platform.

Migrating your data out of Airtable

1. Inventory everything: bases, tables, fields actually in use, automations, scripts, forms and external integrations. Drop the fields nobody fills in.
2. Export cleanly. CSV from a view works for simple tables. The API is better for the full picture because it keeps record IDs, which you need to rebuild links between tables. Download attachments separately.
3. Rebuild the data model. Linked records become real relations, multi-select fields become controlled lists, formulas become rules in code. This is where duplicates and inconsistent statuses get fixed for good.
4. Run a trial migration and ask each team to check its own records in the new app. Only they know when an order is missing.
5. Cut over on an announced date and keep the Airtable base read-only for a few weeks as a safety net.
6. Go step by step if needed. Move the process that hits the limits first and connect the new app to the remaining tables through the API, designing the sync to respect the 5 requests per second limit.

Our legacy data migration guide details the checks to run before and after cutover.

Common mistakes

• Copying Airtable one to one. Workarounds such as duplicated bases and per-person views have no reason to survive. Start from the process.
• Forgetting hidden automations. An email sent by an Airtable automation vanishes quietly if nobody rebuilds it.
• Migrating without the people who type the data. They know which fields matter.
• Underestimating attachments. Thousands of files take time to move and reattach.
• Switching Airtable off on day one. Keep it read-only for a while.

How to pay for the move

The upfront cost is often what keeps teams on a tool that no longer fits. At LPR Studio there are three ways to fund it: a fixed-price build, a subscription where you pay a monthly fee instead of paying for the development, or a SaaS model where the tool becomes a product we publish. We do not bill by the hour. Our comparison of a software subscription vs an upfront build helps you choose.

Your Airtable base already describes your business, so it makes an ideal starting point. Within 5 business days, we present a free prototype of the app that would replace it, on a video call, with your screens and your rules. It is a demonstration, neither paid for nor delivered, so you can compare on evidence. Our guide to the differences between a prototype, an MVP and a POC explains what to expect from it.