Airtable is one of the best on-ramps ever built for small teams that need structure. It is part spreadsheet, part database, part app builder, and for a lot of companies it is the first tool that finally makes operations feel organized. That success is exactly why so many teams keep pushing it past the point where it fits.
There is a tipping point, and it is more predictable than people expect. Once you hit it, the base that felt like a superpower starts to feel like a liability. The goal here is not to talk anyone out of Airtable. It is to name the signals clearly so you can decide when to move the operational core to a real database.
What Airtable Does Well
Airtable is genuinely excellent for a specific job. It gives non-engineers a structured way to model their world and ship a working tool in a day instead of a quarter.
It shines when:
- The data model is still in flux and you need to experiment
- Your team is small enough that everyone can see the whole base
- Views, filters, and simple automations cover most of the workflow
- You need a shared source of truth for a list, pipeline, or inventory
- You want forms, grids, kanban, and calendar views without building any of it
For pilots, lightweight CRMs, content calendars, asset libraries, and project trackers, it is hard to beat.
The Four Scaling Walls
Trouble does not show up as a single failure. It shows up as four walls that almost every growing team hits in roughly the same order.
1. The 50k-row performance wall
Airtable is not a database. It is a hosted record store with a spreadsheet UI on top. Views stay fast while tables are small, but as a single table pushes past tens of thousands of records, filters lag, views time out, the API rate-limits aggregate pulls, and automations that loop over records start missing their windows.
Performance degrades well before you hit the hard cap. If your operational tables are creeping toward 50k rows and still growing, the base is on borrowed time.
2. Formula chain fragility
Rollups that reference lookups that reference formulas that reference linked records are the most common reason Airtable bases fail in production. Each individual formula is fine. The chain is not.
One renamed field, one deleted link, one changed formula, and a downstream rollup silently returns blanks across thousands of records. There is no type system, no migration history, no staging environment, no test coverage. The more logic lives inside formulas, the more fragile the base becomes.
When "why is this number wrong" takes longer than an hour to trace, you have outgrown formula-driven logic.
3. The 50-user seat math
Per-seat pricing is fine at 5 users. It is a real budget line at 50. It is a strategic problem at 150. Once vendors, contractors, clients, or field staff need access, the decision stops being "who should see this" and becomes "who can we afford to pay for."
Teams respond by sharing logins, emailing exports, or building shadow systems in Sheets. All three undermine the reason you centralized in Airtable. If seat cost is shaping who can do their job, the platform is no longer serving the operation.
4. The reporting ceiling
Airtable can chart. It cannot report the way an operations team actually needs to report. Cross-base joins, historical snapshots, cohort math, revenue waterfalls, and SLA breach analysis all push past what the built-in interface can do.
Teams work around this by piping Airtable into a warehouse or exporting to CSV and rebuilding the analysis in a BI tool every month. Both options mean Airtable is no longer the system of record. It is a data entry layer in front of one.
The Migration Path
A migration does not have to be a cutover weekend. The pattern that works is boring and safe: snapshot, mirror, cut over, deprecate.
- Snapshot. Freeze the schema, pull every table to a versioned dump, and document every formula, rollup, and automation in plain language. If no one can explain what a formula does, that is a finding.
- Mirror. Stand up the target database (Postgres is the default right answer) and build a one-way sync from Airtable into it. Run both in parallel for two to four weeks. Reports run from the new database. Data entry stays in Airtable.
- Cut over. Move data entry one workflow at a time, starting with the most painful. Build a thin internal UI on top of the database. Airtable becomes read-only for that workflow, then the next.
- Deprecate. Once every workflow has moved, archive the base. Keep the snapshot. Cancel the seats.
Teams that cut over before mirroring almost always lose data or trust, and trust is harder to rebuild.
What Not to Move
Not everything needs a database. Some data is genuinely spreadsheet-shaped, and forcing it into a schema costs more than it saves.
Leave it in Airtable (or Sheets) if:
- It is a list that one team owns and no other system reads from
- The schema changes faster than the data does
- The whole table fits comfortably under a few thousand rows and will stay that way
- The workflow is "look at it, edit a cell, move on" with no downstream logic
- It is a planning artifact, not a system of record
Content calendars, hiring pipelines for a single role, event run-of-shows, and brainstorm lists usually belong in Airtable forever. The mistake is not using Airtable. The mistake is using Airtable for the thing that now runs the company.
If your team is hitting two or more of the four walls and the workarounds are starting to feel permanent, that is the tipping point. Contact Merkra and we can map which workflows should move, which should stay, and what the target system actually needs to do.