Airtable bases modelled before the three hundredth record arrives
Base architecture, linked-record modelling, interfaces and automation on Airtable, designed so adding the second use case does not mean restructuring the first.
Airtable is a relational database with unusually good views on top, and the relational part is real. A linked record is one object referenced from both sides rather than a copied value. Rollups and lookups aggregate across those links without duplicating anything, so total order value per customer or latest inspection date per site is a field definition rather than an automation maintaining a stored number that can be wrong.
Views are the other genuine advantage. Grid, calendar, kanban, gallery and timeline are windows onto the same rows, filtered per view and non-destructive, and interfaces put a curated slice in front of people who should never see the base. That combination is why Airtable wins against a spreadsheet almost every time and against a real database more often than engineers expect.
Where it stops is querying and scale. A view is a saved question, not a query engine: it cannot join across bases, it recomputes chained formulas as it loads, and a base with two hundred views is a base where nobody can find the right one. Record limits are per base and per plan, writes go to the API ten records at a time, and there are no transactions, so the moment concurrent writers and real integrity constraints matter, the platform is being asked for something it does not offer.
What we build on Airtable
A schema decided before the records exist
Tables are nouns, not screens. Many-to-many relationships get a junction table rather than two link fields pretending, each field has exactly one home, and anything computed is computed rather than typed. Half an hour on this before creating three hundred records is the difference between adding a use case and restructuring for one.
Linked records, lookups and rollups doing the arithmetic
Aggregate across the link rather than storing a total that an automation has to keep true. Rollups with conditions handle most of what people reach for a script to do, and a lookup pulling a field through a link keeps one source for that value instead of a copy that drifts.
Views as the working surface, kept few
A short set of collaborative views that the team agrees on, personal views for everything transient, and locked views where an automation or an interface depends on the filter. Views that exist because one person wanted a sort get deleted, because the cost of a hundred of them is that nobody trusts any of them.
Interfaces for the people who should not see the base
A record-detail interface with the fields that role needs, a list filtered to their own records, and forms for intake. This is what stops the standard mistake of granting base access so somebody can update one field, which is also how a field gets deleted by someone who did not know it fed a rollup.
Automations, scripts and the point of handover
Native automations for triggered writes and notifications, a script step where the logic genuinely needs one, and a hand-off to Make or a small service when the work involves several systems, retries or anything the run history cannot explain. Airtable's automation run log is useful but shallow; once diagnosing a failure needs more than it shows, the logic belongs somewhere with proper logging.
What goes wrong on Airtable
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
The record limit arriving in the middle of a project
Record caps are per base and per plan, and attachments and revision history consume storage alongside them, so the ceiling is usually met sooner than the row count suggests. The answer is rarely a bigger plan: it is deciding what the working set is, archiving everything older than it to Postgres or a warehouse on a schedule, and keeping Airtable for the records people are actually touching.
- 02
Views doing the job a query should be doing
A base with dozens of heavily filtered views over chained formula fields gets slow in a way that looks like Airtable being slow and is really a modelling problem. Each view recomputes, each chained formula recomputes with it, and grid loads degrade. We flatten the formula chains, materialise the values that genuinely need to be stored, cut the view count hard, and move real reporting to somewhere that can answer a question with a query rather than a filter.
- 03
Two systems writing the same field
Airtable's sync tables are read-only by design, which is correct, but pair one with an automation writing back to the source and the record quietly diverges from itself. We fix the direction: one system of record per entity, sync in that direction only, and the receiving side made read-only for those fields so nobody can helpfully correct a value that is about to be overwritten.
- 04
API rate limits and writes that fail at ten records
The REST API takes ten records to a create or update call and enforces a per-base request rate, so a naive integration pushing a thousand rows hits both and starts dropping writes. Integrations get built with chunking, paged reads, back-off on the rate-limit response and a retry that is idempotent; otherwise the recovery from a failure is itself a source of duplicates.
Where Airtable is the wrong answer
Airtable is the wrong answer when you already have Postgres and somebody who can build on it. Its advantage over a real database is the interface, not the storage, and copying operational data into a second system so that it has a nicer grid is how two versions of the truth appear. It is also wrong where integrity has to hold under concurrency (money moving, stock levels, anything where two people acting at once must not both succeed), because that wants transactions and constraints the platform does not have. In both cases we would build an application over the database instead: the same views and forms, with the rules enforced where they cannot be worked around. And if the core object is a piece of work moving through stages with an owner attached, the honest answer is monday.com rather than a base pretending.
Built on Airtable
Projects that did not use Airtable
Here for the argument rather than as evidence of Airtable work. Each one bears on a decision above, and the note says which.
The disciplines behind it
Related reading
Airtable, specifically
Sooner than people expect if views are heavily filtered and formulas are chained, and later than people fear if the base is modelled well. Most performance complaints we are asked to look at trace to a base that grew organically rather than to a hard ceiling. Plan limits are real and worth checking against your growth, but they are usually not what makes a base feel slow.
Often not. If the data already lives in Postgres and someone can build on it, the durable answer is an application over that data rather than a second copy in a spreadsheet-shaped product. Airtable earns its place when nobody is going to build that application, or when the people using it need to reshape their own views without asking an engineer.
Through an interface or a shared view, yes, within limits, and for anything where they need to write back regularly, a purpose-built portal is usually better. The pattern we build is a page showing one person only their own records, writing through the API under a single token, so no external user touches the base and no licence is consumed per person.
With the schema, not the automations. We map every table, link field, rollup and formula dependency first, because that is what tells you which fields are load-bearing and which are abandoned. Only then do the automations get read, and the common finding is a handful that have been failing silently since a field was renamed.
Yes, provided one system owns it and the others read. Airtable is good at this: linked records to suppliers, rollups for stock or pricing views, and an API that other tools can pull from. It stops being suitable when the catalogue drives transactions that must not race each other, at which point the catalogue belongs in the system doing the transacting.
Where this is applied
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no