When Airtable stops being a database
Airtable caps the Team plan at 50,000 records per base, and its write API answers five requests per second no matter which plan you pay for. Most teams never touch either number, and for them Airtable is the right tool and will stay the right tool. The teams who do touch them usually find out in the same week that a customer-facing feature started reading from the base. This is about knowing which group you are in before that week arrives.
The record ceiling is per base, not per account
The Free plan stops at 1,000 records per base. Team, at $20 per collaborator per month billed annually or $24 monthly, raises that to 50,000. Business, at $45, gets you 125,000. Airtable is straightforward about what happens when you arrive: your data stays where it is, and you stop being able to add to it until you upgrade.
Read the unit again. Per base. Not per workspace, not per account. Splitting one overgrown table across two bases to get under the cap costs you every lookup and rollup that crossed the boundary, because those only reach inside a single base. So the choice is to pay more per seat or to reshape your data around a billing line. Neither one is a data modelling decision, which is the part that grates.
The seat math moves in the same direction at the same time. Team bills every collaborator with commenter permission or above. Twelve people who need to watch an order status is twelve times $20 a month, whether or not any of them ever changes a cell. Your cost tracks headcount and record count together, and both of those go up when the business is doing well.
Five requests per second, on every plan
Airtable's API documentation gives one hard number: 5 requests per second per base, with a separate ceiling of 50 requests per second across all traffic from a given personal access token or service account. That per-base figure does not improve when you upgrade. The monthly quota does, from 1,000 calls on Free to 100,000 on Team to unlimited on Business, but the per-second rate is the same on Enterprise Scale as it is on the free tier.
Go over and you get a 429 and a 30 second wait before requests succeed again. Airtable's own advice for higher read volume is to put a caching proxy in front of the API. That advice is honest and it is also the whole argument in one line. Once you are running a cache in front of your database, you are already operating infrastructure. You just do not have access to the part where you would fix the slow query.
The same page reserves the right to change the enforced limits "in our sole discretion, including tiered based on pricing plan." That is a reasonable thing for a vendor to write. It is a harder thing to plan a nightly sync around.
The links between records are the migration
Export shows the real shape of the problem. Airtable exports CSV from a grid view, one table at a time, and there is no single-file export of an entire base. Your records come out clean. The relationships between them do not come with them, so somebody has to rebuild the graph on the other side.
That rebuild is the migration. When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the records themselves were the easy part. The work that needed actual engineering was a four stage ETL that mapped every legacy ID onto a PostgreSQL UUID so nothing downstream lost its parent. An Airtable move is the same shape of job. Budget for the graph, not for the rows.
What you buy with that effort is a database that refuses bad data rather than tolerating it, and code you can put a test around. A foreign key constraint is not a tidier linked record field. It is a rule the database enforces at 2am when the automation that was supposed to enforce it has quietly stopped running. The rest of the stack gets faster as a side effect: Stay World Class went from a Lighthouse performance score of 55.91 to 91 out of 100, with LCP 77% faster.
When staying on Airtable is the right answer
Most Airtable bases should stay Airtable bases. If yours is a planning tool that ten people open during the week, 50,000 records is a ceiling you will never see, and $20 a seat costs less than one afternoon of engineering time. Rebuilding it in Postgres would buy you nothing except a thing you now have to maintain.
Size is not the signal. The signal is when the base stops being a tool your team uses and becomes the system of record that something else depends on: a product reading from it, a billing run, a partner integration on a schedule. At that point you need constraints you can trust and queries you can profile, and Airtable was never sold as a place to get those.
Here is the test I would use. Ask what breaks if Airtable is slow for an hour on a Tuesday afternoon. If the answer is that someone updates a status later than they meant to, stay put and spend the money elsewhere. If the answer is that customers see stale prices, the base is doing a job nobody designed it for, and it got there because the work grew. That is a good problem wearing an inconvenient hat.
