Airtable record limits are fine for lightweight team apps. They become a problem when a base turns into an operational system: customers, jobs, inventory, service requests, attachments, automations, and history all living in one place.
As of May 19, 2026, Airtable's official plan docs list 1,000 records per base on Free, 50,000 on Team, 125,000 on Business, and 500,000+ on Enterprise Scale. Airtable also says those records are cumulative across all tables in a base, so two tables with 25,000 records each count as 50,000 total. Source: Airtable plans overview.
The decision is not "Airtable bad, database good." Airtable is a strong tool when the base is still a flexible app for a focused team. The switch becomes worth considering when record growth, user access, API traffic, history, or ownership starts shaping the way the business works.
Stay In Airtable When
Airtable is often the right tool when:
- The base is comfortably under plan limits
- The number of collaborators is small
- The team values Airtable interfaces, templates, views, and formulas
- The workflow changes often
- Migration risk is low
- The base is not the official source of truth for high-volume operations
That last point is the line. A base can be important without being infrastructure. The trouble starts when daily operations depend on thousands of new records, frequent updates, attachments, automations, and API calls.
Consider A Database-Backed Workspace When
Move beyond Airtable when:
- Record growth is predictable and material
- Many occasional users need access
- Per-collaborator pricing changes who gets invited
- Records need tasks, comments, files, forms, automations, and activity history around them
- API calls are becoming part of the workflow
- Long-term data ownership or retention matters
- The base is now an operational system, not a prototype
The goal is not to recreate Airtable feature by feature. The goal is to move the process into a system that matches its new job.
Airtable Limits To Watch
Airtable's official workspace settings docs list these limits by plan: Free has 1,000 records per base, Team has 50,000, Business has 125,000, and Enterprise Scale has 500,000+. Attachment storage moves from 1 GB to 20 GB to 100 GB to 1 TB by plan. API calls are 1,000 per workspace per month on Free, 100,000 on Team, and unlimited on Business and Enterprise, with a 5 requests-per-second per-base API rate limit on all plans. Source: Airtable workspace settings overview.
Airtable automations also have structural limits. Airtable says you can add up to 50 automations per base and 25 actions per automation, and that monthly automation run limits increase by moving to a higher plan. Source: Airtable automations documentation.
For history, Airtable's record-level revision history varies by plan: two weeks on Free, one year on Team, two years on Business, and three years on Enterprise Scale. Source: Airtable record-level revision history.
Those limits are not hidden. They are product boundaries. The question is whether your workflow still fits inside them cleanly.
What Usually Breaks First
Record count is the obvious limit, but it is not always the first pain.
For small teams, the first problem is often access. A base may need input from sales, operations, finance, support, contractors, or clients. If each meaningful collaborator affects pricing or permissions planning, teams start working around the system.
The second problem is context. Operational records often need more than fields:
- Files
- Comments
- Tasks
- Ownership
- Intake forms
- Status history
- API updates
- Scheduled checks
- Exception handling
When that context spreads across several tools, the base stops being the whole picture.
Compare The Fit
| Scenario | Airtable fit | Database-backed workspace fit |
|---|---|---|
| 1,000 records, 2-3 collaborators | Usually strong | Often unnecessary |
| 30,000 records, 5 active editors | Still workable, but cost and growth matter | Worth evaluating |
| 100,000 records, 10+ editors | Business plan territory | Often a better operational model |
| 500,000+ records or large history | Enterprise Scale territory | Database path becomes more natural |
| Many occasional contributors | Seat and permission planning matter | Broad access is usually easier |
| Existing MySQL data | Import or sync needed | Existing database can sometimes become the base |
Do not move just because a database sounds more serious. Move because the process now needs database behavior: structure, scale, permissions, history, and ownership.
Managed Database Or Bring Your Own?
For most teams, managed is the better first step. It avoids credentials, hosting, backups, and infrastructure decisions before the workflow is even proven.
Bring your own database makes sense when:
- Important data already lives in MySQL
- You need direct control over backups or retention
- Capacity needs exceed managed plan limits
- Company policy requires infrastructure control
- Other systems already depend on the database
That distinction matters. Owning infrastructure is useful only when someone can operate it.
Where InfoLobby Fits
InfoLobby is one database-backed workspace option. It starts with managed MySQL and managed file storage, then adds workspaces, tables, records, forms, tasks, comments, files, automations, activity history, and API access.
It can also connect to your own MySQL, S3, or FTP when the data already exists or the team needs more control.
That makes it relevant when the Airtable problem is not just "we need more rows," but "this base has become how the business runs."
Migration Checklist
Before leaving Airtable, map the real system.
- List each table and the record count.
- Identify formulas, rollups, automations, and interfaces that matter.
- Decide which users need view, edit, admin, or form-only access.
- Export sample data and inspect field types.
- Identify attachments and where they should live.
- Map API users and automation triggers.
- Rebuild one workflow before migrating everything.
The risky migration is the one that treats Airtable as just rows and columns. It is usually more than that.
Bottom Line
Airtable is a good place to prove a workflow. It becomes the wrong place when the workflow has clearly become operational infrastructure and the limits are shaping the business.
Stay when speed, polish, and flexibility matter most. Move when record growth, access, history, API usage, or data ownership have become part of the buying decision.
FAQ
Are Airtable record limits per table or per base?
Airtable says record limits are per base and cumulative across all tables in that base.
Is moving from Airtable always worth it?
No. If the base is small, the team is small, and Airtable's interface is the main value, staying put is usually sensible.
Should we move to a managed database or bring our own?
Start managed unless you have existing production data, infrastructure requirements, or capacity needs that justify owning the database.
What should we migrate first?
Migrate the workflow where limits, access cost, or trust problems are already visible. Do not start with the largest base by habit.