Airtable is comfortable. It feels like a spreadsheet, but it sort of acts like a database. It’s got slick drag-and-drop UI, easy sharing, and workflow features that non-tech folks like. But once your data grows, the cracks start to show. And that’s when the cost of those record limits, hidden caps, and subscriptions become real—and sometimes painful.
Airtable’s record caps: the hidden throttles
Airtable limits how many records (rows) you can store in a base. What does that mean?
| Plan | Records per base | Source |
|---|---|---|
| Free | 1,000 records | Airtable Support |
| Team | 50,000 records | Airtable Support |
| Business | 125,000 records | Whalesync |
| Enterprise | ~500,000 or more (custom) | Airtable Community |
Hitting a cap doesn’t just slow things down—Airtable won’t let you add more records to that base until you upgrade (Whalesync).
If you're managing anything beyond a few thousand rows of active data, hitting those base limits is more than a nuisance—it becomes a blocker. One user on Reddit described Airtable’s record cap as a “complete non-starter” for realistic projects, especially when uptime and scale matter (Reddit).
The kicker? When your team grows or your usage spikes, you don’t just get throttled—you might be forced into a more expensive tier. This makes Airtable more of a scalable trap than a flexible tool in some situations.
The cost of “unlimited” viewers and paid editors
Airtable’s pricing is seat-based, meaning if someone can edit your base, they count as an “editor,” and that adds cost. Airtable does not charge for read-only viewers, but shared editors cost real money (The Digital Project Manager).
If you have a large team with many contributors, or if you want teammates or clients actively editing, the editor seats quickly become the main cost—not the record caps. Add to that the record limit problem, and suddenly a $20/user/month plan starts to feel very restrictive for scaling teams.
What happens after you hit the limit?
When your Airtable base is full:
- A banner warning appears telling you to upgrade (Whalesync)
- You can’t add new records unless you move to a higher-tier plan (Whalesync).
- Upgrades aren’t gradual. You don’t pay per extra record—you move to a whole new plan. That cliff can feel painful if your dataset sneaks past the limit.
- You may need to split your data into multiple bases or sync only a subset of records manually—sacrificing visibility and increasing complexity. This workaround is labor intensive, and can introduce syncing errors or version confusion (Whalesync).
Some users attempt manual partitioning, pulling only recent rows into Airtable and keeping the bulk data elsewhere. It can work for specific workflows, but it sidesteps the original promise of Airtable: everything in one clean, shared workspace.
Owning your database: the cost tradeoff
Running your own database (MySQL, Postgres, etc.) doesn’t come without costs. But these are often predictable, flexible, and under your control—not gated by record limits or per-seat “editor” cliffs.
Costs to think about:
- Server or hosting costs: Even a small DigitalOcean or AWS instance will cost you something—think $5–$20/month for a basic droplet or managed database. You get full control and can scale as needed.
- Backup and retention: You’ll need to plan for data backups, retention policies, and disaster recovery. These can be automated, but they’re your responsibility.
- Interface / GUI: Without a tool like InfoLobby, editing or viewing your data might require writing SQL queries or building a front-end. But UI tools like InfoLobby can sit on top of your database and give your team a friendly interface—without adding usage-based caps or per-editor billing.
- Scaling storage and performance: If your database gets large, you’ll need to manage indexing, query performance, and possibly sharding. But unlike Airtable, there’s no arbitrary row cap. You scale as you need to.
- User permissions and roles: You define who can edit or view data. This isn’t controlled by a product license or editor seat count—it's purely a technical configuration, which means you avoid per-seat pricing surprises.
Because of that, once a database is set up, you’re not paying for each row, each user, or each record snapshot. You control who edits, how much data is stored, and who sees it.
Comparing actual cost scenarios: Airtable vs “BYO MySQL + InfoLobby”
Let’s walk through a few rough scenarios. I’ve simplified the math to highlight relative cost differences—your own situation might vary, but the point is to surface the real tradeoffs.
| Scenario | Airtable cost | BYO database cost + InfoLobby | Notes |
|---|---|---|---|
| Small project, 2,000 records | Free tier: okay at first, but hitting 2x Free plan. Likely need to upgrade to Team soon → ~$20/month/user Airtable Support | Cheap hosting ($5–$10/month), plus InfoLobby free beta | Airtable works at start, but scales poorly. Self-hosted is slightly more work, but free of record cliffs. |
| Mid-size dataset, 40,000 records, 3 editors | Team plan: $20 × 3 = $60/month; record cap almost hit, so risk bumping up again Airtable Support | Server $10–$20/month + InfoLobby; no per-editor cost | Airtable: big seat cost + tight record cap. Self-hosted: stable cost, easier to grow. |
| Growing inventory or CRM with 100K+ records, 10 editors | Likely Business plan: $45 × 10 = $450/month, but record cap at 125K might push to Enterprise with custom pricing Whalesync | Database hosting (say $20–$40/month) + InfoLobby; very cheap per-editor cost | Airtable becomes expensive and possibly restrictive. Self-hosted gives more freedom to grow. |
| Massive record history (500K+), dozens of users | Enterprise custom plan. Pricing opaque, but may be thousands per month. Tools and admin controls required. Whalesync | Higher-end database hosting (maybe $50+/month), InfoLobby, backups, etc. but still no per-editor charge | Airtable might be usable, but costly; self-hosted provides better predictability and avoids surprise seat-based billing. |
A key takeaway: with Airtable you’re paying for both seats and scale. You pay when you add users and when your row count grows. Sometimes you also pay for automation runs or storage—but the record cap is a silent throttle. With a self-hosted database and the right UI (cough InfoLobby), your cost structure is more predictable. You decide when to scale, and how much to spend.
Hidden friction and costs
Beyond just dollars and record caps, Airtable has other friction points that compound as your project grows:
- Migration headaches: Exporting a full Airtable base isn’t always trivial, especially if you want to move to an SQL database later. Field types, linked records, and backups can break during CSV or JSON transfers.
- Sync and slice workflows: If you try to workaround record caps by syncing only parts of your dataset, you’ll spend months juggling subsets, syncing tools, and data duplication. This becomes a maintenance burden.
- Editor seat management: Upgrading and downgrading editor seats is a manual task. It’s easy to accidentally leave editors active and get charged later, or to lose collaboration when you downgrade too aggressively.
- Automation caps: Automation executions are also throttled on Airtable’s plans. If you build serious automation pipelines, your usage can exceed those caps, forcing an upgrade even if your record count is modest. Orb
- Revision history and attachments: If your workflows rely heavily on file attachments or version clearance, Airtable’s storage caps and history retention policies can become a limiting factor. Exporting or migrating attachments at scale can be messy.
These are not direct financial costs, but they tend to cost time, developer effort, and headaches, especially as your base ages or your team grows.
When Airtable still “just works”
I don’t mean to bash Airtable. It’s a great tool for certain use cases. If your data is lightweight (a few thousand records), your collaboration needs are modest, and you don’t mind its workflow structure, it can be faster to get started than building your own setup.
If you don’t expect your base to grow past 50,000 records, or you’re fine manually migrating when scale becomes an issue, Airtable is convenient. If the idea of spinning up a server, managing backups, and handling permissions doesn’t appeal to you, Airtable is a friction-free way to get something up quickly. Its built-in automation, dashboards, and interface tools make it a low-code option that often wins in early-stage projects.
But if you're building for growth—tracking inventory, CRM pipelines, historical event logs, or team workflows—you’ll bump into Airtable’s record limits and editor seat costs long before you expect. That’s when owning your database pays off.
Final thoughts
Airtable’s limits aren’t just numbers on a pricing page. They’re brakes that activate as you scale. What looks like “unlimited” at first becomes very limited, very fast. Higher records, more users, and automation flows all push you closer to upgrade cliffs, and those cliffs tend to coincide with the moments your project is growing—or failing.
Owning your database gives you control over your growth. It means you pick how much it costs to scale. It avoids surprise cap hits, and lets you build and grow without worrying about hidden throttles or seat-based pricing traps. You do take on hosting and backup responsibilities—but for many projects, that tradeoff is worth it.
If you want a friendly UI on top of a database, tools like InfoLobby let you build team-facing database apps without being boxed in by record caps or per-editor pricing. When done right, self-hosted + GUI means fewer surprises, more flexibility, and more freedom.
If you want, I can walk you through a migration case—a real-world example showing how a growing database moved off Airtable to InfoLobby + MySQL, and what the cost and maintenance differences turned out to be.