Airtable alternative: when to fix your base, and when to build

Airtable charges per seat. As reported on 25 October 2026, Team is US$20 per seat a month billed annually (US$24 monthly) and Business is US$45 billed annually (US$54 monthly). There is a free plan for up to five editors, and Enterprise Scale is priced by quote. One report says that on Team, people who only comment are billed as seats, and on Business they are not; check how Airtable counts your collaborators before you budget.

Five seats on Team cost US$3,600 over three years, less than a custom build, and 10 seats cost US$7,200, about the same. Business is where the numbers part: US$16,200 for 10 seats and US$32,400 for 20 billed annually, against a custom system's ceiling of US$5,600 to US$8,600. At 20 seats even Team costs US$14,400 over three years. So below about 10 seats on Team, price is not a reason to leave; past that, or on Business, it can be.

Airtable's linked records are real: one record referenced from both sides, with rollups and lookups that aggregate across links without copying data. Views and interfaces give each group its own window onto the same rows. That is why it beats a spreadsheet almost every time, and why a small team that wants to shape its own data should usually stay. A base with a tangled schema is a design problem, and it can be fixed inside Airtable.

• Records: Business is reported at about 100,000 to 125,000 records per base, and the reports disagree on the exact figure. Check the current limit for your plan.
• Automations: each plan caps automation runs, and a busy base can reach the cap.
• API: integrations that sync often can run into the plan's API limits, and writes go through the API ten records at a time.
• Permissions: access is managed through bases, interfaces and shared views, which becomes fragile when different people must see different records.
• Integrity: there are no transactions, so concurrent writers and strict data rules are hard to enforce.

Some of these are solved inside Airtable, by splitting a base, archiving old records or moving automations to Make or n8n. When several apply at once, the platform is being asked for something it was not designed to do.

The clearest sign is that people outside the team depend on it. Customers submit through a form, read their status in a portal, or receive data from an integration, and a renamed field or a broken automation reaches them. At that point the base needs what production software has: changes tested before they go live, permissions enforced in one place, and a schema that cannot be changed by accident from a view. That is when a custom application on a real database is worth its build cost, whatever the seat count.