Airtable vs a custom database
Airtable is a genuine step up from a spreadsheet and a genuine step below an application. It holds until the number of records, the permissions, or the logic outgrows what a table view can express. Use Airtable to find the right shape. Build when people need screens for their job rather than a view of a table.
Is Airtable enough, or do we need a real database?
How to decide:
A small team is modelling a process that is still changing weekly. Buy. That flexibility is worth more than correctness, and it needs no engineering.
You need real field types, relationships between tables, and views per person. Configure. Structure without engineering is exactly what Airtable is for, editable by someone who is not a developer.
Record volume is large enough to hurt performance. Build. That is one of the ceilings, and no amount of configuration moves it.
Permissions need to be per-row rather than per-view. Build. A view is not a permission, and treating it as one exposes data.
Logic has to run reliably rather than when someone opens the tab. Build. Rules should be enforced by the database rather than by convention.
People need a screen designed around their job rather than a grid of every field. Build. The interface is still a table. Once that is the constraint, you have outgrown it.
What drives the cost:
How settled the shape is. Model it in Airtable until the shape stops changing. A stable base is a finished specification, and building from one is far cheaper than building from a conversation.
Permissions granularity. Per-row permissions and reporting that does not depend on someone exporting a view are real engineering, and they are the usual reason for the move.
Screens versus grids. Screens shaped around tasks instead of records are where the build effort goes, and where the daily time saving comes from.
What people get wrong:
Mistaking a view for a permission. Views organise what someone sees. Permissions that need to be per-row rather than per-view are one of the ceilings you hit.
Building before the shape stops changing. Model it in Airtable first. A stable base is a finished specification, and building from one is far cheaper than building from a conversation.
Expecting an application from a table. The interface is still a table. Once people need a screen designed around their job, no configuration will produce it.
What does Airtable do well?
Structure without engineering. Real field types, relationships between tables, and views per person, all editable by someone who is not a developer.
What ceilings do you hit with Airtable?
Record volume and performance on large bases. Permissions that need to be per-row rather than per-view. Logic that has to run reliably rather than when someone opens the tab.
What do you gain by building?
Screens shaped around tasks instead of records. Rules enforced by the database rather than by convention. Reporting that does not depend on someone exporting a view, and ownership of the data model.
What is a reasonable path off Airtable?
Model it in Airtable until the shape stops changing. A stable Airtable base is a finished specification, and building from one is far cheaper than building from a conversation.
Last reviewed 22 August 2026