When do you outgrow Airtable?

Ever opened your base and found four versions of the same email field? This base probably came to life as simple "Contacts", "Deals", and "Payments" tables, and now it feels like it is time to switch. Everything is just so messy, and any day now, the workflow that you built to support the initial version of your business might collapse under the weight of lookup columns that you do not really trust anymore.

A note, my dear reader: your base probably has not hit its limit yet, and this switch could very well be unnecessary and expensive.

When do you outgrow Airtable?

You outgrow Airtable when the operating requirements around the data exceed what Airtable can deliver cleanly, and not when the base merely "feels messy".

Messy is not exactly quantifiable, so we like to measure it by the five forcing functions, and one has to actually be present:

1. Your users cannot be inside Airtable. The people who need to use this are customers, applicants, or the public, and they will never have Airtable accounts, so what they see has to be a front end you built, and branded to the client.
2. You need authentication and row-level permissions. Logins that you own, and rules deciding which records each person can see, wherein one client must never be able to load another client's rows.
3. The rules have to move out of formulas and into code. An audit trail, so you can see who changed what and when. Server-side validation, which means a rule that cannot be clicked past no matter who is typing. And transactions, wherein two writes either both succeed or both roll back, so a payment never lands without the deal attached to it.
4. You are hitting a documented limit, and you can prove it. Records, attachments, API rate limits, or automation runs, checked against Airtable's own limits rather than against something you half-remember.
5. The client needs ownership of the code, the deployment, and the roadmap. Not the data, which is exportable already, but the thing that reads it.

And let's be clear about what is not on that list: relational complexity. Airtable is a relational database with a visual front end, so linked records, junction tables, self-links, and rollups are things it was designed to do.

Which Airtable limits are real?

The limits worth taking seriously fall into categories, and we highly recommend checking your numbers against Airtable's own plans and limits page, because a figure you half-remember from two years ago is not a plan.

Record and attachment capacity is the one almost everybody reaches for first, though it arrives later than expected. What people do not anticipate is API throughput and pagination, and it sure bites the hardest: the REST API hands back records in pages, so anything reading a large table has to page through, and anything writing at volume has to respect the rate ceiling. Automation-run allowances matter once a base is doing real operational work daily. Per-seat economics matter the moment the client's whole team needs access, and that is a cost curve, not a technical wall. And interface and permission constraints are the boundary you feel earliest on a client-facing base.

Make sure to notice that hitting a limit is not the same as needing to leave. Batching writes, caching reads, backing off on retries, archiving cold records, or changing plan resolves most of these, in this case without touching the architecture.

Which problems are actually schema problems?

Say a client comes to you asking what they should be switching to, because they've hit their limit with Airtable and they are done arguing about it. You open the "Master" base, and here is what you actually find.

What each row is doing wrong:

1. Rows 1, 2, and 4 are a person, a company, and a person again, all in a table that also holds two deals. The Type field is the only thing telling them apart, which means every view, every formula, and every automation has to filter on it before it can do anything.
2. John's email appears four times across three spellings, and one of them, j.harper@dummy.com, is wrong. Nobody knows it's wrong, because there is nothing to check it against.
3. "John is decision maker, Priya signs off" is a many-to-many relationship with a role attached, sitting in a Notes field where no formula can read it and no filter can find it.
4. The company is "Harper Rowe Ltd" in three rows and "Harper Rowe" in two, so grouping by company gives you two companies.
5. And the primary field is doing four jobs at once: a name, a status, a call log, and a shouted instruction. Every linked record elsewhere in the base would display "John (new, called Tues, DO NOT EMAIL)" as its label.

That base is genuinely something I would never want to work in, and the client is not wrong to be frustrated. But look at that list again, and notice what is not in it: not one of those is a limit we talked about earlier.

So here's what you would do instead of quoting them for a migration. You split "Master" into three tables, wherein Contacts holds people,

Deals holds the work,

and Payments holds money that has come in.

And then a fourth table, where "Deal Contacts" holds one row for each person working on each deal, and the job they do on it. Here, John decides on the website rebuild, Priya approves it, and Priya is the one you invoice on the retainer. This fact can only be assembled when the two tables are combined together, which is what a junction table is for.

The email lives in Contacts once, and a lookup pulls it through to wherever else you need to read it. And the primary field goes back to being an identity, wherein the notes about John live in a field called Notes, where they always belonged.

And the client stays on Airtable, in this case for the price of an afternoon.

What requirements usually force a custom application?

This is a capability question rather than a size question, and it has three answers.

Airtable interfaces. Make sure to stay with an interface when your client just needs a tidy screen for their own team to work in, over the same base you already built. You choose which fields they can edit and which are read-only, you hide the internal ones completely, and a button on the page can fire off an automation without them ever seeing how it works. If the manager and the staff need different things, build two interfaces rather than one clever one, and share only the interface, so nobody ever lands in the raw table.

A custom webpage on top of Airtable. We've seen that the honest trigger for going custom is because of who the end users are. If the page is for customers or applicants, people who will never have an Airtable login, or it has to sit inside your client's existing website and look like the rest of it, or the layout is more than what Airtable's interface builder will give you, then you build the page yourself and leave Airtable underneath as the place where the data lives. Your page asks Airtable for records over its API, and sends new ones back the same way.

For anything public, the token belongs in a serverless function that proxies the request, never in client-side JavaScript, because the page source is readable by everyone who visits.

A full application. Consider this only when the interface, permissions, logic, and maintenance requirements together no longer fit the Airtable-plus-interface model. Not when one is straining.

Should you repair, build alongside, or migrate?

Three paths, and the middle one is the one that gets skipped.

The middle row deserves better. The client keeps the base they know how to operate, and the customer-facing surface stops looking like a spreadsheet. What you take on in exchange is two systems that have to agree, plus API behaviour you now own: pagination, rate limits, field names that must match your Airtable column names EXACTLY, and a token that has to live somewhere safe. It is the same hybrid trade-off you make when choosing between Make, n8n, and custom code.

And on ownership, which is usually the word doing the arguing: it is not binary. Ask instead whether the data is exportable, who controls the infrastructure, who owns the code, and who answers when it breaks at 2am. A client who says they want to own their system usually means one or two of those.

What does migration actually involve?

Let's be specific about the work a shallow comparison skips, because this is where timelines go wrong.

1. Export and field mapping. The fields that do not map cleanly are the ones that eat your week.
2. Rebuilding every relationship. Linked records do not survive a CSV export. Your Deals will come out holding the contact's name as plain text, and reconnecting them is manual work.
3. Moving the files. Anything sitting in an attachment field has to be pulled out and re-hosted somewhere.
4. Keeping a cross-reference of old record IDs to new ones. Every workflow, form, and integration pointing at a record is pointing at an ID, and those all change.
5. Authentication. Airtable was quietly handling logins for you, and now you own that.
6. Replacing the interface. Whatever your client was clicking on has to be rebuilt before they can do their job.
7. Running both systems in parallel on live data, then the cutover itself, and a rollback plan you could actually execute at 9am on a Monday.
8. Reworking every workflow pointed at the old base. Every Make scenario, every n8n workflow, every form.

And let's not forget the quiet one: Airtable gave you a usable interface for free. A database, on its own, gives you nothing to look at.

What questions come up most often about outgrowing Airtable?